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Abstract 

y  This  thesis  effort  focuses  on  designing  and  implementing  the  Knowledge- Based 

Software  Assistant  System  (KBSAS)  for  the  Structured  Analysis  Design  Technique 

(SADT)  method  developed  by  Softech,  IncT 

o 

A  Graphics  Editor  7  is  used  to  create  specific  Structured  Analysis  (SA)  dia¬ 
grams  and  a  graphical  symbol  syntax  is  derived  from  these  diagrams.  The  devel¬ 
opment  of  the  KBSAS  is  divided  into  two  parts:  the  design  and  implementation 
of  a  graphics  translator  and  an  application  of  a  knowledge-based  system  for  syntax 
checking. 

First,  the  objective  of  the  translator  is  to  map  a  subset  of  the  graphical  symbol 
syntax  from  a  SA  diagram  into  the  first  order  predicate  calculus.  The  SA  diagram 
information  is  represented  in  a  set  of  predicate  data  forms. 

Secondly,  the  objective  of  a  knowledge-based  system  is  to  evaluate  adherence 
to  proper  SADT  syntax.  This  is  accomplished  by  generating  SA  rules  associated 
with  either  an  activity  box  or  boundary  arrows.  The  requirements  analyst  and  the 
designer  are  provided  with  a  means  of  recovering  from  a  graphical  symbol  syntax 
error(s)  through  a  display  window. 

Specific  emphasis  focuses  on  a  comprehensive  mapping  of  the  graphical  symbol 
syntax  to  predicate  logic  as  well  as  development  of  an  application  of  a  rule-based 
system  using  this  capability.  ^ 

i 


'SADT  is  a  trademark  of  Softech,  Inc. 

2developed  by  Steven  E.  Johnson  at  the  Air  Force  Institute  of  Technology. 


VIII 


EXPERT  SYSTEM  IN  SOFTWARE  ENGINEERING  USING 
STRUCTURED  ANALYSIS  AND  DESIGN  TECHNIQUE(SADT) 


I.  Introduction 


Ifnckyrou  ml 

Then*  have  been  several  thesis  efforts  in  the  field  of  Computer-Aided  Software 
Engineering  (CASH)  tools  to  support  the  analysis  and  design  stages  of  the  software 
process  at  the  Air  Force  Institute  of  Technology  (A FIT).  One  of  these  efforts  was  a 
(Graphics  Editor  for  structured  analysis  with  data  dictionary  support  1  (9). 

The  SAtool  is  one  of  several  requirements  analysis  and  design  CASE  tools  based 
on  the  IDEFo  syntax2.  'This  tool  provides  a  means  of  developing  IDEFo  diagrams 
*  and  data  dictionary  support.  This  tool  also  saves  information  derived  from  the 
diagrams;  however,  SAtool  does  not  have  the  capability  of  checking  IDEFo  syntax. 
To  solve  this  problem,  a  validation  scheme  for  checking  the  consistency  of  IDEFo 
methodology  and  providing  error  messages  with  error  recovery  is  required.  Using 
the  predicate  data  form,  a  specific  IDEFo  diagram  from  the  SAtool  is  evaluated 
for  adherence  to  proper  SADT  syntax  through  the  use  of  a  know  ledge- based  expert 
system  (KBES).  The  earlier  version  of  the  validation  tool  was  hosted  on  the  SUN 
workstations4  with  the  expert  system  written  in  Prolog- 1  and  run  on  a  Zenith  Z-248 
computer  (10). 

'The  Graphics  Editor  is  called  SAtool. 

‘IDEFo  is  a  version  of  SofTech’s  SADT. 

3Sonietimes  IDEFo  diagrams  are  called  SADT  diagrams. 

4SUN  is  a  trademark  of  SUN  Microsystems,  Inc. 
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The  intent  of  this  thesis  effort  is  to  continue  the  earlier  investigation  by  expand¬ 
ing  the  rule  set,  thereby  developing  a  more  integrated  environment  and  analyzing 
its  performance. 

Staff  rnc.nl  of  the  Problem 

The  specific  objectives  of  this  thesis  investigation  are  to  extend  the  earlier 
predicate  calculus  definitions  of  SADT  syntax  to  the  more  complete  set  of  SADT 
constructs,  to  extend  the  expert  system  rule  set  based  on  the  new  definitions,  to 
integrate  the  graphical  translation  process  in  C  with  the  expert  system  on  a  SUN 
workstation,  and  also  if  time  permits,  to  use  the  structure  of  the  knowledge-based 
SADT  syntax  system  to  incorporate  the  design  knowledge  of  a  specific  software 
application. 


Assumptions 

For  the  purpose  of  this  investigation,  several  assumptions  were  made, 

1.  The  primary  users  of  this  tool  are  AFIT  graduate  students  and  faculty. 

2.  The  users  of  this  tool  are  familiar  with  the  Structured  Analysis  methodology. 
•5.  The  users  of  this  tool  are  familiar  with  the  SAtool. 

4.  Although  not  necessary,  the  users  of  this  tool  are  also  familiar  with  Prolog. 
Research  Approach 

The  thesis  objective  is  accomplished  through  the  development  of  two  major 
components:  an  IDEF0  Diagram  Translator  and  an  IDEF0  Syntax  Expert  System. 
The  IDEFo  syntax  for  SAtool  was  studied,  followed  by  a  review  of  the  design  and 
implementation  of  SAtool.  The  previous  syntax  rules  of  the  syntax  validation  tool 
were  also  reviewed.  These  were  updated  and  changed  as  necessary  to  reflect  the 
development  of  the  new  system.  The  reusable  components  of  the  syntax  validation 


tool  were  extracted,  new  code  was  written,  and  new  syntactical  rules  were  generated 
to  implement  the  changes  considered  by  the  analysis. 

The  IDEF0  Diagram  Translator  has  three  parts.  The  function  of  the  first  part 
is  to  create  a  set  of  predicate  data  forms  from  a  SAtool  activity  box  in  the  IDEF0 
Diagram  in  order  to  check  the  activity  IDEFo  syntax.  The  function  of  the  second  part 
is  also  to  generate  a  set  of  the  predicate  data  forms  from  the  current  IDEFo  Diagram 
and  its  parent  IDEF0  diagram  in  order  to  check  the  boundary  IDEFo  syntax.  In  the 
third  part,  the  objective  is  to  create  a  file  for  the  current  IDEF0  diagram  in  the  form 
of  a  set  of  the  predicate  data  to  speedically  check  the  boundary  IDEFo  syntax. 

The  IDEEq  Syntax  Expert  System  consists  of  two  major  parts:  an  inference 
engine  and  a  rule  base.  The  inference  engine  was  selected  as  backward  chaining 
strategy  (search)  called  BC35  which  is  a  directed  problem-solving  (pattern  matching) 
process  written  in  prolog.  The  rule  base  consists  of  activity  rules  and  boundary  rules. 
The  activity  rules  check  the  ’activity’  IDEF0  syntax  and  the  boundary  rules  are  to 
check  the  ’boundary’  IDEF0  syntax. 

The  system  checks  IDEF0  syntax,  displays  error  messages,  and  provides  editing 
suggestions  interactively. 

All  software  conformed  to  the  software  engineering  standards  in  AFIT’s  System 
Development  Documentation  Guidelines  and  Standards  draft  #4  (8). 

Materials  and  Equipment 

The  materials  and  enuipment  for  this  effort  were  provided  by  the  AFIT  De¬ 
partment  of  Electrical  and  Computer  Engineering.  The  following  items  were  used: 

1.  SUN  workstations. 

2.  Berkeley  Unix  6  version  4.3. 

^developed  by  Dr.  Frank  M.  Brown  at.  AFIT. 

'’Unix  is  a  trademark  of  AT&T. 


1-3 


3.  Suncore  graphics  and  Suntools  environment. 

4.  The  software  developed  in  this  thesis  effort. 

5.  Prolog  environment. 

Overview  of  Thesis 

This  thesis  is  divided  into  six  chapters.  Chapter  I  explains  the  history  of  AFIT’s 
CASE  tools  based  on  SADT  syntax  and  defines  some  of  the  terms  to  be  used.  Chap¬ 
ter  II  presents  a  literature  review  of  the  current  issues  that  affect  this  thesis  effort. 
The  requirements  for  the  translator  and  the  expert  system  for  this  thesis  effort  are 
presented  in  chapter  III.  Chapter  IV  and  V  describe  the  high  level  and  detailed  de¬ 
sign  and  implementation  phases  respectively.  In  chapter  VI,  the  conclusions  and  the 
recommendations  are  addressed  for  this  thesis  effort. 
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II.  Literature  Review 


Introduction 

The  focus  of  this  thesis  investigation  is  to  design  and  implement  an  application 
of  expert  system  formulation  for  checking  the  syntax  of  IDEFo  diagrams  as  derived 
from  SAtool.  The  current  S Atool  is  one  of  requirements  analysis  CASE  tools  based  on 
the  IDEFo  syntax  which  is  a  subset  of  SADT  syntax.  The  purpose  of  this  literature 
review  is  to  discuss  the  issues  of  the  requirements  analysis  phase,  AFIT  Structured 
Analysis  Syntax  as  a  subset  of  IDEFo  syntax,  and  a  rule-based  expert  system 
architecture. 

Requirements  Anahjsis  Phase 

The  software  life  cycle  represents  the  functionally  distinct  portions  of  develop¬ 
ment  and  use  of  a  software  product  from  birth  to  death.  The  classic  life  cycle  model 
as  shown  in  Figure  2.1  may  be  divided  into  six  major  phases:  system  engineering  and 
analysis  phase,  software  requirements  analysis  phase,  design  phase,  implementation, 
testing,  and  finally  maintenance  phase  (3).  The  requirements  analysis  process  fo¬ 
cuses  specifically  on  software  by  definition.  To  understand  the  nature  of  the  software 
to  be  built,  the  software  analysts  must  understand  the  information  domain  for  the 
software,  as  well  as  the  required  function,  performance  expectations,  and  interfacing 
(12).  Analysts  should  develop  the  software  specification  using  a  documentation  tool 
so  that  they  may  later  compare  the  requirements  against  the  solution  because  a  com¬ 
plete  specification  of  software  requirements  is  imperative  to  the  success  of  a  software 
development  effort.  No  matter  how  well-designed  or  well-coded,  poorly  specified 
software  will  disappoint  the  user  and  bring  grief  to  the  developer  (12).  A  number  of 
software  analysis  and  specification  methods  have  been  developed  and  each  method 
has  its  own  notation  and  point  of  view;  however,  there  is  a  set  of  general  principles 
for  requirements  analysis: 
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Figure  2.1.  Classic  Software  Life  Cycle  Model(  12:20) 


1.  The  information  domain  and  the  functional  domain  of  a  problem  must  be 
represented  by  syntax  and  understood  by  humans. 

2.  The  problem  must  be  partitioned  in  a  manner  that  uncovers  detail  in  a  hier¬ 
archical  fashion. 

3.  Logical  and  physical  representations  of  the  system  should  be  developed  (12). 

Many  requirements  analysis  methods  and  tools  have  been  developed  during  the 
past  decade.  The  methods  and  tools  may  be  divided  into  three  broad  analysis  cat¬ 
egories:  data  flow-oriented  analysis,  data  structure-oriented  analysis  and  language- 
based  formal  specification  (12).  The  software  requirements  analysis  methods  were 
originally  developed  to  be  applied  manually;  however,  each  of  these  methods  is  avail¬ 
able  in  a  computer-aided  format  (12).  Several  of  computer-aided  analysis  tools  have 
been  developed  to  automate  the  generation  and  maintenance  of  what  was  originally  a 
manual  method.  These  tools  make  use  of  a  graphical  notation  for  analysis.  This  class 
of  tools  produces  diagrams,  aids  in  problem  partitioning  and  maintains  a  hierarchy  of 
information  about  the  system  (12).  These  CASE  tools  enable  the  analyst  to  update 
information  and  compare  the  connections  between  new  and  existing  representations 
of  the  system.  For  example,  the  SAtool  enables  the  analyst  to  produce  a  structured 
analysis  diagram  and  a  data  dictionary  and  maintain  these  in  a  data  base  that  can 
be  analyzed  for  correctness,  consistency,  and  completeness.  The  computer-aided 
requirements  analysis  approach  provides  benefits  as  followings: 

•  improved  documentation  quality  through  standardization  and  reporting 

•  better  coordination  among  analysts  in  that  the  data  base  is  available  to  all 

•  gaps,  omissions,  and  inconsistency  are  more  easily  uncovered  through  cross- 
reference  maps  and  reports 

•  the  impact  of  modifications  can  be  more  easily  traced 

•  maintenance  costs  for  the  specification  are  reduced  (12:200). 
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AFIT  Structured  Analysis  Syntax 

The  SADT  syntax  is  based  on  a  tabulation  of  some  40  notations  in  a  paper 
by  Douglas  T.  Ross  of  Softech,  Inc.  (14).  The  notations  give  the  definitions  and 
the  semantics  of  the  SADT  graphic  language.  The  SADT  methodology  provides  a 
means  of  handling  large  complex  system  problems.  The  SADT  notations  consist  of 
two  major  constructs:  rectangular  boxes  and  arrows.  Rectangular  boxes,  identified 
as  verbs  (activities),  provide  for  the  decomposition  of  the  system  parts.  Arrows, 
labeled  with  nouns  (data  structures),  represent  the  data  flow  relationship  among  the 
l'ectangular  boxes.  The  rectangular  boxes,  arrows  and  English  text  build  a  diagram 
which  represents  the  whole  system. 

The  U.S.  Air  Force  Program  for  Integrated  Computer-Aided  Manufactui-ing 
(ICAM)  has  developed  the  IDEF0  (ICAM  Definition  Method  Zero)  1  language. 
IDEFo  syntax  is  a  derivative  of  the  SADT  syntax  and  is  used  for  software  require¬ 
ments  analysis.  The  AFIT  Structured  Analysis  syntax  implemented  by  SAtool  is 
represented  in  Table  2.1  (9). 

Column  1  in  the  table  shows  the  line  numbers  of  the  SADT  graphical  notations 
(14:20).  Column  2  shows  the  name  by  which  each  notation  was  l'eferenced  in  SAtool. 
Column  3  indicates  the  page  in  the  SAtool  User’s  Manual  (9). 

The  SAtool  provides  a  means  of  drawing  the  IDEF0  diagrams  and  storing  infor¬ 
mation  derived  from  the  diagrams.  Each  diagram  is  drawn  and  stored  individually. 
An  example  of  an  IDEFo  diagram  drawn  by  SAtool  is  shown  in  Figure  2.2.  Boxl, 
Box2,  and  Box3  are  for  ACTIVITY  NAMEs  and  the  numbers  in  the  rectangular 
boxes  represent  NODE  NUMBERs.  The  numbers  in  small  rectangular  boxes  show 
FOOTNOTES.  The  label  in  a  small  circle  is  for  TO/FROM  ALL.  Ini,  Out2,  Con.22 , 
Mechl ,  and  etc.  represent  line  LABELs  for  INPUT,  OUTPUT,  MECHANISM,  and 

'See  the  reference  17.  ICAM  Definition  method  IDEFo  Sep. 1979. 
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Ross  Article 
Line  Number 
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ARROW 


INPUT 


OUTPUT 


CONTROL 
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ACTIVITY  NAME 


LABEL 


BRANCH 
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SPREAD 
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Figure  2.2.  An  example  of  IDEFq  diagram 


2-6 


Figure  2.3.  A  typical  Expert  System  Structure 

CONTROL.  II,  Cl,  01,  Ml,  and  etc.  also  represent  ICOM  CODEs  for  boundary 
arrows. 


Expert  System 

Knowledge-based,  expert  systems  are  likely  to  be  applied  to  requirements 
analysis  tasks.  However,  the  definition  of  the  knowledge  base  (facts,  rules, 
and  necessary  inferences  to  perform  analysis)  will  remain  a  significant 
challenge  in  the  foreseeable  future.  (12:201) 

Figure  2.3  presents  the  components  of  a  general  expert  system:  knowledge  base 
(rules),  data  base  (facts;  working  memory),  inference  engine,  and  user  interface. 

The  knowledge  base  can  be  represented  by  many  different  methods,  such  as 
predicate  calculus,  lists,  frames,  semantic  nets,  production  rules,  etc.  In  this  thesis 
effort,  the  language  of  if-then  rules  was  selected  to  represent  the  knowledge  base,  since 
it  provides  several  features  which  are  modularity,  incrementability,  modifiability,  and 
transparency  of  the  system.  The  if-then  rule  consists  of  two  parts  :  condition  and 
conclusion.  The  logical  condition  part  may  contain  one  or  more  premises  linked  by 
the  conjunctions  AND,  OR,  or  NOT.  If  the  conditions  are  true  (met),  the  conclusion 
part  is  also  true  (fired). 
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The  data  base  is  a  portion  of  working  memory  where  the  current  status  of 
problem  is  stored.  Initially,  the  lists  of  object,  attribute,  and  value  (OAV)  triple 
derived  from  a  IDEFo  diagram  are  stored.  Then  the  new  lists  of  OAV  triple  from 
the  inference  process  are  added.  The  data  base  also  stores  a  list  of  rules  that  have 
been  examined,  and  fired  in  some  order.  The  rule  order  can  be  given  later  if  the  user 
or  developer  requires  an  explanation  of  the  reasoning  process. 

The  inference  engine  is  called  a  rule  interpreter  because  its  operation  is  like 
a  software  interpreter  for  a  computer  language.  The  rule  interpreter  examines  the 
rules  in  a  specific  order  searching  for  matches  to  the  initial  and  current  conditions 
given  in  the  working  memory.  As  the  rules  continue  to  fire,  they  will  reference  one 
another  and  form  an  inference  chain.  The  firing  of  a  rule  may  add  new  facts  to  the 
working  memory,  which  gives  the  rule  interpreter  additional  information  on  which 
to  proceed.  This  process  continues  until  the  solution  is  found. 

Given  a  desired  goal,  there  are  two  basic  approaches  in  searching  for  a  solution: 
forward  chaining  and  backward  chaining.  In  forward  chaining ,  the  rule  interpreter 
tries  to  match  a  fact  in  the  working  memory  to  the  situation  stated  in  the  condition 
part.  If  a  fact  in  the  working  memory  has  been  matched,  then  that  rule  is  fired. 
The  conclusion  part  could  generate  a  new  fact  that  is  stored  in  the  knowledge  base. 
This  new  fact  may  be  used  in  the  search  for  the  next  proper  rule.  This  process 
continues  until  the  solution  of  the  given  goal  is  satisfied.  In  backward  chaining ,  the 
rule  interpreter  starts  examining  the  conclusion  part  to  look  for  a  match.  If  a  match 
is  found,  then  the  working  memory  is  updated  recording  the  conditions  that  the 
rule  stated  as  necessary  for  supporting  the  matched  conclusion  (13).  The  backward 
chaining  process  continues  with  the  system  repeatedly  attempting  to  match  the 
conclusion  part  against  the  current  system’s  status.  The  corresponding  condition 
parts  matched  are  used  to  produce  new  intermediate  goal  states  which  are  recorded 
in  the  working  memory.  This  process  continues  until  the  given  goal  is  proved. 

Finally,  the  user  interface  provides  a  means  of  communication  between  the 
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user  and  the  system.  The  user  interface  asks  questions  or  presents  menu  choices  for 
entering  initial  facts  in  the  data  base.  Any  intermediate  communications  during  the 
problem-solving  process  are  taken  care  of  by  the  user  interface. 

Expert  systems  are  far  more  useful  if  they  have  the  following  additional  fea¬ 
tures: 

•  Modulai'ity: 

Each  rule  defines  a  small,  relatively  independent  piece  of  knowledge. 

•  I ncrement  ability: 

New  rules  can  be  added  to  th  :  knowledge  base  relatively  independently  of  other 

rules. 

•  Modifiability  (as  a  consequence  of  modularity): 

Old  rules  can  be  changed  relatively  independently  of  other  rules. 

•  Support  systems  transparency  (4:316-317). 

Summary 

This  thesis  effort  concentrates  on  translating  an  IDEF0  diagram  drawn  by  the 
SAtool  into  a  set  of  predicate  data  forms  during  requirements  analysis.  It  also  focuses 
upon  developing  an  application  of  a  rule-based  expert  system  for  evaluating  IDEF0 
syntax.  The  literature  review  in  this  chapter  provides  understanding  concerning  the 
main  subjects  of  this  thesis  investigation:  requirements  analysis  phase  of  software 
development,  IDEF0  syntax,  SAtool,  and  rule-based  expert  system  components. 
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III.  System  Requirements  Analysis 


Introduction 

This  thesis  investigation  is  classified  into  two  major  categories.  First,  the 
IDEF0  Diagram  Translator  is  to  be  redesigned  and  reimplemented  to  translate  any 
IDEF0  diagrams  drawn  by  SAtool  into  a  set  of  predicate  data  forms.  It  should  create 
a  necessary  file  to  be  used  for  checking  IDEFo  syntax.  The  second  category  is  to 
design  and  implement  the  IDEFo  Syntax  Expert  System  which  is  an  application  of  a 
knowledge- based  expert  system. 

This  chapter  presents  the  considerations  related  to  the  development  of  the 
IDEFo  Diagram  Translator  requirements,  IDEFo  Syntax  Expert  System  require¬ 
ments,  formalization  criteria,  the  IDEF0  diagrams  of  this  tool,  and  validation  test 
requirements. 

Considerations  of  the  Previous  Studies 

The  SAtool  provides  an  interactive  graphics  editor  for  drawing  IDEF0  diagram 
and  a  means  of  generating  data  dictionary  information  (9:3-2).  The  SAtool  also 
provides  the  capability  to  check  IDEFo  syntax  for  an  activity  box  in  any  IDEF0 
diagrams(  10:2-1).  The  SAtool  does  not  provide  a  means  of  checking  IDEFo  syntax  for 
any  boundary  arrows  with  the  parent  IDEF0  diagram,  however,  the  SAtool  provides 
a  means  of  checking  IDEFo  syntax  for  only  one  activity  box  in  any  IDEF0  diagram. 
The  current  SAtool  checks  IDEF0  syntax  through  Zenith  Z-248  workstations  using 
the  expert  system  written  in  Prolog- 1.  The  improved  tool  in  this  thesis  effort  should 
interface  with  the  SAtool,  produce  a  set  of  predicate  data  forms  for  the  activity  boxes 
and  the  boundary  arrows  information  in  any  IDEF0  diagrams,  and  provide  the  more 
completed  capability  of  checking  IDEF0  syntax.  Also,  the  revised  tool  should  satisfy 
all  requirements  of  the  previous  SAtool  (9). 
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IDEFq  Diagram  Translator  Requirements 

The  function  of  the  IDEF0  Diagram  Translator  is  to  generate  the  predicate 
data  forms  from  any  IDEFo  diagrams.  The  IDEFo  Diagram  Translator  should  act 
as  a  bridge  between  the  current  SAtool  and  the  IDEFo  Syntax  Expert  System.  The 
current  SAtool  was  written  in  the  C  language  and  used  graphics  software  packages 
called  SunView  and  SunVVindow  environment.  Thus,  the  IDEFo  Diagram  Translator 
should  operate  with  the  current  SAtool.  Since  the  current  SAtool  provides  a  means 
of  checking  IDEFo  syntax  for  only  one  activity  box,  to  check  syntax  for  boundary 
arrows,  the  IDEFo  Diagram  Translator  should  be  redesigned  and  reimplemented 
in  the  C  language.  The  predicate  data  forms  generated  by  the  IDEFo  Diagram 
Translator  should  be  the  initial  data  base  for  the  IDEFo  Syntax  Expert  System.  It 
is  necessary  to  formalize  the  IDEF0  syntax  to  produce  the  predicate  data  forms  and 
to  check  the  IDEF0  syntax  in  the  IDEF0  diagrams.  IDEFo  syntax  is  formalized  as 
follows: 

1.  The  formal  definition  of  IDEFo  syntax  must  contain  the  syntax  information  in 
any  IDEFo  diagram  and  be  described  syntactically, 

2.  provide  the  means  to  determine  syntax  errors  in  any  IDEFo  diagram, 

3.  provide  a  domain  where  the  definition  of  consistency  can  be  given, 

4.  serve  as  the  final  arbiter  in  cases  where  there  is  disagreement  concerning  the 
exact  meaning  of  the  representation,  and 

5.  should  be  able  to  be  implemented  in  a  computer  system  (10:2-3). 

The  next  section,  Requirements  analysis  Diagrams ,  describes  the  functional 
decompositions  for  the  IDEF0  Diagram  Translator. 


IDEFq  Syntax  Expei't  System  Requirements 

The  IDEFq  Syntax  Expert  System  should  allow  the  user  to  check  the  activity 
IDEFo  syntax  and  the  boundary  IDEFo  syntax  in  any  IDEFo  diagrams  using  a 
created  predicate  data  file. 

The  backward  chaining  search  is  useful  when  there  are  many  more  rules  than 
desired  goals.  A  backward  chaining  inference  engine  was  selected  called  BC31  which 
directed  problem-solving  processes  and  acts  as  a  rule  interpreter  (6)  because  the 
backward  chaining  strategy  is  useful  when  there  are  many  more  rules  than  desired 
goals.  The  rule  base  should  be  able  to  support  the  knowledge  of  IDEF0  syntax  with 
the  inference  engine  in  accordance  with  the  activity  boxes  and  the  boundary  arrows. 
To  simplify  the  rule  base,  the  rule  base  should  be  consisted  of  two  separate  parts 
because  the  boundary  arrows  information  is  not  necessary  in  checking  the  activity 
IDEFo  syntax  and  the  activity  boxes  information  is  not  needed  for  examining  the 
boundary  IDEFo  syntax.  The  first  part,  called  the  Activity  IDEFo  Syntax  rule  base, 
should  allow  the  checking  of  the  Activity  IDEF0  Syntax  using  a  created  predicate  file 
which  includes  all  information  pertaining  to  an  activity  box  in  any  IDEF0  diagram. 
The  second  part,  called  the  Boundary  IDEF0  syntax  rule  base,  should  allow  for 
the  checking  of  the  Boundary  IDEFo  Syntax  using  a  created  predicate  file  which 
includes  all  information  pertaining  to  the  boundary  arrows  in  any  IDEFo  diagram 
and  its  parent  IDEFo  diagram. 

Validation  Test  Requirements 

Some  parameters  can  be  used  for  evaluating  the  conformity  of  the  requirements 
with  the  tool.  As  mentioned  in  Chapter  I,  the  important  parameters  are  the  accuracy 
with  which  the  tool  checks  the  IDEF0  syntax  and  the  capability  of  which  the  tool 
interactively  displays  error  messages  and  editing  suggestions.  Other  parameters  to 
be  considered  are  user  friendliness,  maintainability,  compatibility,  and  consistency. 

‘developed  by  Dr.  Frank  M.  Brown  at  AFIT. 
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Requirements  Analysis  Diagrams 

This  section  presents  the  functional  model  which  defines  and  describes  the 
functional  decompositions  for  the  IDEFo  Diagram  Translator  and  the  IDEFo  Syntax 
Expert  System  discussed  in  the  previous  sections.  The  IDEFo  diagrams  in  this 
section  are  based  on  the  analysis  of  processes  or  activities  and  illustrate  one  level 
of  the  functional  decomposition  with  the  facing  page  text.  The  facing  page  text 
provides  additional  information  that  is  not  easily  inferred  from  the  diagram.  The 
Data  Dictionary  entries  provide  even  more  detailed  information  in  accordance  with 
each  activity  and  data  item  (22:4-5). 

Figure  3.1  shows  the  top  most  level  IDEF0  diagram  for  the  overall  system  of  the 
SAtool.  The  purpose  of  the  Provide  SAtool  function  is  to  create  and  edit  an  IDEFo 
diagram,  its  data  dictionary  information,  and  the  facing  page  text  interactively  (9). 
The  function  also  involves  the  process  which  produces  the  predicate  data  forms  to 
be  used  for  the  knowledge  base  of  the  IDEFo  Syntax  Expert  System. 

Figure  3.2  displays  the  first  decomposition  of  the  top  most  level  of  Provide 
SAtool  activity.  This  decomposition  shows  the  two  primary  functions:  Provide  5/4 
Editor  and  Translate  Diagram.  The  Provide  5/1  Editor  function  is  to  draw  the 
activity  IDEFo  diagram  and  to  generate  its  data  dictionary  information  and  its 
pacing  page  text  for  activity  and  data  entry.  The  Translate  Diagram  activity  provides 
a  means  of  translating  IDEF0  diagrams  into  predicate  data  forms. 

Figure  3.3  shows  the  decomposition  of  the  Translate  Diagram  activity  into  three 
functional  components:  Translate  Activity,  Translate  Boundary ,  and  Save  Diagram. 
The  Translate  Activity  provides  a  means  of  translating  an  activity  box  in  any  IDEF0 
diagrams  into  a  set  of  predicate  data  forms  through  the  translation  rules  of  the 
activity  box  and  saving  it  into  a  temporary  file.  The  Translate  Boundary  operation 
is  the  process  which  translates  the  boundary  arrows  in  any  IDEF0  diagrams  into  a 
set  of  predicate  data  forms  through  the  translation  rules  of  the  boundary  arrows  and 
saves  it  into  a  temporary  file.  Finally,  Save  Diagram  provides  a  means  of  translating 
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A-0  Provide  SAtool 


Abstract:  Provide  SAtool  provides  a  means  of  mechanism  by 
which  the  user  is  able  to  draw  Activity  IDEFO  Diagrams. 
From  these  diagrams,  Facing  Page  Text  and  Data  Dictionaries 
for  Activities  and  Data  and  Predicate  Data  forms  are 
generated. 


AUTHOR:  Capt  Kim,  intaek 

DATE: 04/ 10/90 

READER 

PROJECT:  SAtool 

REV: 1.1 

DATE 

User  Interface! 


Translation  Rules 


User  Files 
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Facing  Page  Text^ 
IDEF8  Diagram 

_ CRT  Inf 

Predicates 


NODE: 

TITLE:  Provide  SAtool 

NIXBER:  C-l 

A-0 

Figure  3.1.  Provide  SAtool 
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AO  Provide  SAtool 

Abstract:  Provide  SAtool  provides  the  user  a  mechanism  by 

which  the  user  is  able  to  draw  Activity  IDEFO  Diagrams. 
From  these  diagrams.  Facing  Page  Text,  Data  Dictionaries  for 
Activities  and  Data,  and  Predicate  Data  forms  are  generated. 

A1  Provide  SA  Editor  provides  a  means  of  drawing 

Activity  IDEFO  Diagrams.  From  these  diagrams.  Facing  Page 
Text  and  Data  Dictionaries  for  Activities  and  Data  are 
generated. 

A2  Translate  Diagram  provides  a  means  of  translating 
IDEFO  Diagrams  into  Predicate  Data  Forms. 


Figure  3.2.  Provide  SA  Editor 
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the  IDEFo  diagram  into  a  set  of  predicate  data  forms  and  saving  it  into  a  file  which  is 
specified  by  the  user.  Further  functional  decompositions  are  presented  in  Appendix 
A. 


Summary 

This  chapter  presented  the  requirements  analysis  for  the  development  of  IDEFo 
Diagram  Translator  and  IDEFo  Syntax  Expert  System.  Since  this  investigation 
extends  the  earlier  version  of  the  SAtool,  this  tool  should  satisfy  all  requirements 
of  the  earlier  version.  This  tool  should  also  provide  a  means  for  displaying  error 
messages  and  editing  suggestions.  The  functional  decompositions  for  this  tool  was 
presented  in  Requirements  Analysis  Diagrams  section. 

The  next  two  chapters  use  the  requirements  developed  in  this  chapter  as  the 
fundamental  for  designing,  implementing,  and  testing  of  IDEF0  Diagram  Translator 
and  IDEFo  Syntax  Expert  System. 
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A2  Translate  Diagram 

Abstract:  Translate  Diagram  provides  the  user  a  means  of 
translating  IDEFO  Diagrams  into  Predicate  Data  Forms. 

A21  Translate  Activity  provides  a  means  of  translating 
an  activity  box  in  any  IDEFO  Diagrams  into  a  set  of  predicate 
data  forms  through  the  translation  rules  of  the  activity  box. 

A22  Translate  Boundary  provides  a  means  of  translating 
the  boundary  arrows  in  any  IDEFO  Diagrams  into  Predicate  data 
forms  through  the  translation  rules  of  the  boundary  arrows. 

A23  Save  Diagram  provides  a  means  of  translating  the 
IDEFO  Diagram  into  a  set  of  the  predicate  data  forms  and 
saving  it  into  a  file  which  user  specifies  interactively. 


Figure  3.3.  Translate  Diagram 
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IV.  High  Level  Design 


Introduction 

The  purpose  of  this  chapter  is  to  present  and  justify  the  preliminary  software 
design  for  the  IDEF0  Diagram  Translator  (IDT)  and  the  IDEF0  Syntax  Expert  Sys¬ 
tem  (ISES).  Throughout  the  remainder  of  this  investigation,  IDT  and  ISES  refer  to 
these  two  particular  systems.  Preliminary  design  is  associated  with  the  transforma¬ 
tion  of  requirements  into  the  software  architecture.  The  transformation  starts  with 
several  considerations  of  previous  studies  addressed  in  Chapter  III.  The  modified 
screen  layout  and  menu  selection  are  then  presented.  In  addition,  the  main  func¬ 
tions  of  the  IDEF0  Diagram  Translator,  the  IDEF0  Syntax  Expert  System,  and  the 
associated  components  are  introduced. 

Previous  Study  Considerations 

Since  the  tool  should  interface  with  the  SAtool,  the  hardware  and  the  software 
to  be  used  are  already  chosen.  Thus,  the  Sun3  and  the  Sun4  workstations  using 
the  SunOS  and  the  SunView  window-based  environment  are  lequired  for  this  tool 
because  the  SAtool  was  developed  through  the  Sun  workstation.  Also  since  the 
IDEFo  validation  tool  was  implemented  with  the  C  language  in  order  to  translate 
the  IDEFo  diagram  into  the  predicate  data  forms,  the  C  language  is  used  to  expand 
the  capability  of  the  translating  process.  This  decision  is  reasonable  because  many 
portions  of  the  validation  tool  and  the  SAtool  could  be  directly  reused.  Appendix  C 
represents  a  summary  of  the  data  structures  which  are  used  for  the  earlier  version 
of  SAtool  and  this  thesis  effort. 

Screen  Layout  and  Menu  System 

In  this  thesis  investigation,  the  screen  layout  of  the  SAtool  and  the  validation 
tool  should  be  modified  by  adding  new  menu  items  for  checking  IDEFo  syntax. 
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Figure  4.1  is  a  picture  of  the  actual  screen  layout  used  by  the  tool. 

The  actual  screen  is  divided  into  five  windows:  the  Input  Window,  the  Message 
Window,  the  Selection  Window,  the  Diagram  Window,  and  the  Data  Dictionary 
Window  in  vertical  order.  The  function  of  each  window  is  the  same  as  in  the  SAtool 
except  the  function  of  the  Selection  Window.  The  Selection  Window,  located  directly 
below  the  Message  Window  is  used  for  selecting  the  menu  which  contains  the  next 
desired  operation.  The  six  ovals  arranged  in  left  to  right  order  are:  RECALL  DGM, 
EDIT  DD,  EDIT  FPT,  MISC  FUNC,  SAVE  DGM,  and  CHECK  SYNTAX.  The 
function  of  RECALL  DGM  is  to  read  a  previously  saved  IDEFo  diagram.  The  EDIT 
DGM  function  is  to  create  and  edit  an  IDEF0  diagram  according  to  its  attribute 
menus.  The  function  of  EDIT  DD  is  to  create  and  edit  data  dictionary  information. 
The  function  of  EDIT  FPT  is  to  edit  facing  page  text  of  an  IDEF0  diagram.  The 
function  of  MISC  FUNC  is  to  save  an  IDEF0  diagram,  change  directory,  start  new 
diagram,  and  exit  SAtool.  The  function  of  SAVE  DGM  is  to  save  the  graphics 
information  (.gph  extension)  and  the  data  dictionary  information  (.dbs  extension)  in 
files  under  the  name  provided  by  the  user.  Finally,  The  CHECK  SYNTAX  function 
is  to  translate  and  save  IDEFo  diagrams  as  predicate  data  forms  and  to  check  IDEF0 
syntax.  Figure  4.2  presents  a  picture  of  all  menu  selections  to  be  used  and  their 
decompositions. 

Since  the  functions  of  all  menu  selections  are  the  same  as  those  of  the  SAtool 
except  Activity,  Boundary,  and  Save  (-pro)  selections,  the  other  detailed  descriptions 
of  the  functions  of  the  menu  selections  except  for  above  three  are  available  in  reference 
(9).  Further  descriptions  of  Activity,  Boundary,  and  Save  (.pro)  selection  functions 
are  discussed  in  the  next  section. 

IDEFo  Diagram  Translator 

The  translator  for  the  IDEFo  diagram  is  used  to  translate  the  IDEFo  graphical 
features  into  predicate  data  forms.  The  requirements  for  the  formalization  criteria 
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have  been  discussed  in  Chapter  III.  There  are  many  ways  to  formalize  the  graphical 
language  such  as  PSL/PSA,  TAGS,  SREM,  and  etc  (12:163-209).  Also,  there  are 
lots  of  different  ways  to  represent  knowledge  for  expert  system,  for  example  rules, 
semantic  nets,  frames,  scripts,  predicate  logic,  and  others  (13:63-102).  In  this  thesis 
investigation,  predicate  logic  is  used  to  translate  an  IDEFo  diagram  into  a  set  of 
predicate  data  forms.  The  predicate  logic  is  often  used  as  a  means  of  knowledge 
representation  in  expert  systems  and  is  the  basis  for  logic  programming.  Many  spe¬ 
cialists  regard  it  as  the  single  most  important  knowledge  representation  method.  The 
predicate  logic  also  provides  for  symbols  to  represent  objects  and  then  allows  these 
symbols  to  be  used  as  components  of  statements.  As  shown  in  Figure  4.3,  the  IDEFo 
graphical  notations  used  by  the  SAtool  consist  of  two  major  constructs:  activity  box 
and  arrow.  The  informations  related  to  an  activity  box  are  ACTIVITY  NAME,  AC¬ 
TIVITY  NUMBER,  INPUT,  OUTPUT,  CONTROL,  and  MECHANISM.  Although 
there  are  many  types  of  arrows  such  as  BRANCH,  JOIN,  SPREAD,  BUNDLE,  and 
others,  the  arrow  type  can  be  considered  to  be  one  of  either  the  boundary  arrow  type 
connected  on  the  parent  IDEFo  diagram,  the  tunnel  arrow  type,  or  the  interboxes  ar¬ 
row  type  which  is  connected  between  two  boxes  in  the  same  IDEFo  diagram.  Among 
the  arrow  types,  only  the  boundary  arrow  type  has  the  information  of  the  relation¬ 
ships  between  an  IDEF0  diagram  and  its  parent  IDEFo  diagram.  This  boundary 
arrow  type  can  be  considered  as  either  boundary  INPUT,  OUTPUT,  CONTROL, 
or  MECHANISM.  The  other  arrow  types  are  related  to  an  activity  box  in  an  IDEFo 
diagram.  Thus,  it  is  useful  to  translate  and  create  separately  the  graphical  informa¬ 
tions  for  an  activity  box  and  the  boundary  arrows.  Another  reason  for  translating 
the  IDEFo  diagram  into  a  set  of  predicate  data  forms  and  generating  seperately  its 
information  is  to  reduce  the  size  of  the  predicate  data  file  for  checking  IDEF0  syntax 
and  to  provide  simplicity  of  the  knowledge  base  as  well.  Therefore,  the  function  of 
the  IDEFo  Diagram  Translator  is  divided  into  three  parts.  The  function  menus  of 
CHECK  SYNTAX  in  Figure  4.2  show  the  functions  of  the  IDEF0  Diagram  Transla- 
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Figure  4.3.  IDEF0  Diagram  with  Parent 
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tor.  The  Activity  selection  menu  is  used  to  translate  and  create  a  file  of  the  predicate 
data  forms  automatically  from  an  activity  box  clicked  on  by  the  user  in  any  IDEF0 
diagrams.  The  Boundary  Arrow  selection  menu  is  used  to  translate  and  create  auto¬ 
matically  a  file  of  the  predicate  data  forms  from  the  boundary  arrow  information  in 
the  current  IDEFo  diagram  and  the  predicate  data  file  of  its  parent  IDEFo  diagram. 
Finally,  Save  (.pro)  selection  menu  is  used  to  translate  an  IDEFo  diagram  into  a  set 
of  predicate  data  forms  and  to  save  it  to  a  file  that  the  user  specifies.  This  saved  file 
is  to  be  used  for  checking  boundary  IDEF0  syntax  with  the  next  decomposed  IDEFo 
diagram 

IDEFo  Syntax  Expert  System  Components 

The  IDEFo  Syntax  Expert  System  provides  a  means  of  checking  the  IDEFo 
syntax  in  any  IDEFo  diagrams  using  a  created  predicate  data  file.  The  components 
of  ISES  are  the  inference  engine  (control  strategy)  which  is  selected  as  BC3,  the 
knowledge  base  (rule  base)  which  consists  of  the  IDEFo  syntax  rules,  the  data  base 
(working  memory)  which  is  made  up  of  a  list  of  facts  derived  from  the  IDEF0  diagram, 
and  the  user  interface  which  supplies  facts  or  other  information  to  the  ISES  and 
transmits  expert  advise  to  the  user  as  shown  in  Figure  2.3. 

Inference  Engine.  An  inference  engine  applies  the  knowledge  to  the  solution 
of  a  specific  problem.  In  general,  the  same  control  strategy  can  be  used  to  reason 
out  all  kinds  of  actual  problems  because  it  is  separated  from  the  knowledge  base 
for  the  particular  application.  One  of  the  inference  rules,  called  modus  ponens,  is 
used  in  producing  a  proof  which  allows  a  fact  or  truth  to  be  inferred  from  two  other 
statements.  For  example,  if  propositions  Pand  P  implies  Q  are  true,  then  proposition 
Q  is  true.  The  inference  engine  repeatedly  applies  the  method  of  modus  ponens  to 
the  knowledge  base  to  extract  a  specific  value  or  solve  a  particular  problem.  During 
consultation  of  the  IDEF0  Syntax  Expert  System,  the  following  functions  should  be 
performed: 
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•  interface  with  users 

•  obtain  and  load  the  knowledge  base 

•  apply  the  rules  in  the  knowledge  base  and  the  facts  in  the  working  memory  to 
achieve  goals 

•  display  the  messages  about  the  results  of  checking  IDEFq  syntax. 

In  Chapter  II,  the  backward  chaining  control  structure  has  been  represented. 
Backward  chaining  is  often  beneficial  when  there  are  many  more  facts  than  final 
goals  (thus  called  goal-driven  reasoning).  Since  the  number  of  facts  in  any  IDEFo 
diagram  is  many  more  than  that  of  goals  for  IDEFo  Syntax,  backward  chaining  is 
useful  for  the  ISES  design. 

Knowledge  Base.  The  heart  of  the  expert  system  is  the  knowledge  base,  which 
contains  the  problem-solving  knowledge  of  the  particular  application.  In  the  IDEFo 
Syntax  Expert  System,  the  knowledge  base  is  represented  in  the  form  of  if... then 
rules  and  is  separated  into  two  parts:  the  knowledge  base  of  the  IDEF0  syntax  for 
an  activity  box  and  the  knowledge  base  of  IDEF0  syntax  for  boundary  arrows.  The 
former  includes  the  IDEFo  syntax  rules  and  goals  about  an  activity  box  focused 
on  ACTIVITY  NAME,  ACTIVITY  NUMBER,  INPUT,  OUTPUT,  and  MECHA¬ 
NISM.  The  latter  is  made  up  of  the  IDEFo  syntax  rules  and  goals  about  boundary 
arrows  focused  on  boundary  INPUT,  OUTPUT,  CONTROL,  and  MECHANISM. 
Since  the  IDEFo  syntax  has  semantic  meanings,  it  is  difficult  to  represent  com¬ 
pletely  the  IDEFo  syntax  to  the  knowledge  base.  For  example,  ACTIVITY  NAME 
should  be  used  in  the  form  of  a  verb,  which  needs  rules  as  many  as  the  number  of 
verbs  in  the  dictionary. 


In  the  previous  section,  IDEFo  Diagram  Translator ,  the  reasons  why  two 
different  predicate  data  fdes  are  generated  separately  have  been  discussed.  Since 
the  knowledge  base  should  be  consistent  with  the  IDEF0  Diagram  Translator,  the 


knowledge  base  for  IDEFo  Syntax  Expert  System  should  be  separated  into  two  sub¬ 
components.  It  is  also  necessary  to  separate  it  into  two  sub-components  in  order  to 
reduce  the  complexity  and  redundcncy  of  the  knowledge  base  because  while  check¬ 
ing  IDEFo  syntax  for  an  activity  box,  the  knowledge  base  for  boundary  arrows  is 
unnecessary.  The  names  of  the  two  separated  portions  of  the  knowledge  base  are  the 
Activity SArule  for  the  activity  IDEFo  syntax  rules,  and  the  BoundarySArule  for  the 
boundary  arrow  IDEFo  syntax  rules.  A  detailed  discussion  of  IDEFo  syntax  rules 
follows  in  Chapter  V. 

Data  Base  (Working  Memory).  The  data  base  contains  a  broad  range  of  infor¬ 
mation  about  the  current  status  of  the  problem  being  solved.  The  temporary  output 
files  of  the  IDEF0  Diagram  Translator  become  the  initial  data  base  for  the  IDEFo 
Syntax  Expert  System  in  accordance  with  checking  IDEF0  syntax  of  the  activity 
box  or  the  boundary  arrow.  While  checking  the  IDEF0  syntax,  the  data  base  also 
contains  a  list  of  rules  that  have  been  examined  and  fired.  After  checking  IDEF0, 
the  sequence  of  the  rules  fired  can  be  given  in  order  to  explain  the  reasoning  process. 

User  Interface.  The  user  interface  allows  the  user  to  communicate  with  the 
expert  system  and  also  provides  the  user  with  an  insight  into  the  problem-solving 
process  carried  out  by  the  inference  engine.  There  are  several  ways  to  communicate 
with  the  expert  system  such  as  questions  and  answers ,  menu  choices ,  statements ,  and 
others.  In  the  ISES,  the  user  interface  facility  as  a  piece  of  software  is  contained  in 
the  inference  engine  and  provides  a  means  of  asking  questions  and  answering  through 
the  verbose  and  why  trace  operation.  It  also  provides  menu  choices  in  order  to  check 
IDEF,)  syntax  for  activity  box  or  boundary  arrow. 

Testing  Techniques 

There  are  two  common  techniques  to  test  software  referred  to  as  black  box  and 
white  box  testing  (12:470). 


Black  box  testing  enables  the  software  engineer  to  derive  sets  of  input  condi¬ 
tions  that  will  fully  test  all  functional  requirements  for  a  program.  This  attempts  to 
find  errors  in  the  following  categories: 

•  incorrect  or  missing  functions, 

•  interface  errors, 

•  errors  in  data  structures, 

•  performance  errors,  and 

•  initialization  and  termination  errors  (12:484). 

White  box  testing  is  a  test  method  based  on  the  control  structure  of  the  pro¬ 
cedural  design.  This  is  used  to  derive  the  following  test  cases: 

•  guarantee  that  all  independent  paths  within  a  module  have  been  exercised  at 
least  once, 

•  exercise  all  logical  decisions  on  their  true  and  false  sides, 

•  execute  all  loops  at  their  boundaries  and  within  their  operational  bounds,  and 

•  exercise  internal  data  structures  to  assure  their  validity  (12:472). 

As  mentioned  earlier,  the  black  box  testing  method  is  useful  at  this  point  be¬ 
cause  it  focuses  on  the  functional  requirements  of  the  software.  The  functions  defined 
in  the  requirements  analysis  phase  are  compared  to  the  requirements  specification  to 
be  sure  that  all  requirements  are  satisfied.  In  the  case  of  the  IDEFo  Diagram  Trans¬ 
lator,  the  black  box  test  can  be  applied.  For  example,  does  the  IDT  translate  IDEF0 
diagram  into  a  set  of  predicate  data  forms  which  contains  all  syntactical  information 
of  the  IDEFo  diagram?  In  the  case  of  the  IDEFo  Syntax  Expert  System,  the  black 
box  test  can  also  applied.  For  example,  does  the  ISES  contains  all  syntactical  rules 
of  IDEFo  diagram  comparision  with  the  requirements  specification. 
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Summary 


This  chapter  presented  a  high  level  software  design  for  the  IDEFo  Diagram 
Translator  and  the  IDEF0  Syntax  Expert  System.  To  be  consistent  with  the  earlier 
version  of  IDT,  several  considerations  of  the  earlier  version  are  addressed.  The 
screen  layout  and  the  menu  system  modified  were  presented.  In  addition  to,  the 
main  functions  of  the  IDEFo  Diagram  and  the  components  of  the  IDEFo  Syntax 
Expert  are  also  addressed,  and  the  test  design  was  introduced.  The  next  chapter 
presents  low  level  design,  implementation,  and  software  test  for  the  IDEFo  Diagram 
Translator  and  the  IDEF0  Syntax  Expert  System. 
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V.  Low  Level  Design  and  Implementation 


Introduction 

This  chapter  discusses  the  low  level  design  and  implementation  of  an  IDEFo 
Diagram  Translator  and  an  IDEFo  Syntax  Expert  System  specified  in  the  previous 
design  chapter.  The  IDT  becomes  a  portion  of  the  SAtool  and  translates  IDEFo 
diagrams  into  the  predicate  data  forms.  These  predicate  data  forms  are  used  for 
checking  IDEFo  syntax  and  become  the  initial  data  base  (working  memory)  of  the 
IDEFo  Syntax  Expert  System. 

IDEFo  Diagram  Translator  Design 

The  flow  diagram  model  of  the  IDEF0  Diagram  Translator  is  shown  in  Figure 
5.1.  There  are  three  components  in  Figure  5.1:  Translate  Activity,  Translate  Bound¬ 
ary,  and  Save  Diagram  for  the  IDT.  These  three  components  accept  an  IDEFo  dia¬ 
gram,  User’s  Choice,  and  Parent  Predicate  as  inputs  and  generate  outputs  such  as 
Activity  Predicate,  Boundary  Predicate,  and  Diagram  Predicate  applied  by  Trans¬ 
lation  Rules.  The  function  of  Translate  Activity  is  to  translate  an  activity  box  in 
any  IDEF0  diagram  into  the  predicate  data  forms  and  produce  a  file  of  the  predi¬ 
cate  data  forms.  The  file  name  of  the  predicate  data  forms  for  an  activity  box  is 
CHECKBOX. PRO  (temporary  file).  The  function  of  Translate  Boundary  is  to  trans¬ 
late  boundary  information  in  any  IDEFo  diagram  and  the  parent  diagram  related  to 
the  current  IDEF0  diagram  into  the  predicate  data  forms  and  generate  a  file  of  the 
predicate  data  forms  which  is  a  temporary  file.  The  file  name  of  the  predicate  data 
forms  for  the  boundary  information  is  CHECKBOUNDARY. PRO  (temporary  file). 
The  function  of  Save  Diagram  is  to  translate  the  IDEFo  diagram  into  the  predicate 
data  forms  and  save  into  a  file  of  *.pro.  The  symbol  *  is  a  name  which  the  user  enters. 
The  *.pro  file  is  used  to  check  IDEFo  syntax  about  the  boundary  arrows.  Appendix 
B  shows  the  structure  charts  for  the  IDEFo  Diagram  Translator  implementation. 
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Figure  5.1.  Flow  Diagram  for  IDEFo  Diagram  Translator 
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CONTROL 

INPUT 

NAME 

OUTPUT 

NUMBER 

MECHANISM 

Figure  5.2.  A  Typical  Activity  Box 

The  earlier  version  of  the  SAtool  was  implemented  in  C.  To  reuse  many  modules 
of  the  earlier  SAtool  without  modifications  or  with  slight  modifications,  a  decision 
was  made  to  proceed  using  C  language  for  the  IDEF0  Diagram  Translator. 

Translation  Rules 

Since  the  IDEFo  Diagram  Translator  consists  of  three  components,  it  is  rea¬ 
sonable  to  discuss  the  translation  rules  according  to  Activity  and  Boundary. 

Activity.  A  typical  drawing  model  for  an  activity  box  is  shown  in  Figure  5.2. 
The  IDEFo  Diagram  Translator  should  produce  Activity  Predicate  data  forms  which 
include  all  graphical  information  of  an  activity  box.  As  discussed  in  Chapter  IV, 
the  information  of  an  arbitrary  activity  box,  which  is  based  on  NAME,  NUMBER, 
INPUT,  OUTPUT,  CONTROL,  and  MECHANISM  is  shown  in  Figure  5.2.  Among 
the  information,  the  NAME  is  a  key  information  because  the  other  information 
depends  on  the  NAME.  For  example,  if  the  NAME  is  known  among  activity  boxes, 
the  other  information  can  be  extracted  easily.  Table  5.1  presents  the  translation 
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Term 

Predicate 

Triple 

NAME 

activityname(is,  NAME) 

[activityname,  is,  NAME] 

NUMBER 

NAME(numberJs,  NUMBER) 

[NAME,  numberis,  NUMBER] 

INPUT 

NAME(input is,  LABEL) 

[NAME,  input  Js,  LABEL] 

OUTPUT 

NAME(output Js,  LABEL) 

[NAME,  output  is,  LABEL] 

CONTROL 

NAME(controUs,  LABEL) 

[NAME,  controlis,  LABEL] 

MECHANISM 

NAME(  mechanism  Js,  LABEL) 

[NAME,  mechanismJs,  LABEL] 

NUMBER  OF 
INPUTS 

NAME(has  input  .number, 

COUNT) 

[NAME,  hasinputjiumber, 

COUNT] 

NUMBER  OF 
OUTPUTS 

NAME(has.control_number, 

COUNT) 

[NAME,  has.output jiumber, 

COUNT] 

NUMBER  OF 
CONTROLS 

NAME(has_control-number, 

COUNT) 

[NAME,  has-control_number, 

COUNT] 

NUMBER  OF 

MECHANISM: 

NAME( 

1  has_mechanism_number, 

COUNT) 

[NAME, 

has_mechanism_number, 

COUNT] 

Table  5.1.  Translation  Rules  for  Activity  Box 

rules  for  an  activity  box.  Column  1  in  the  table  5.1  presents  the  information  items 
of  an  activity  box.  Column  2  shows  predicate  data  forms  of  the  items.  Since  the 
predicate  data  forms  produced  by  IDEFo  Diagram  Translator  become  the  initial 
data  base  of  the  IDEFo  Syntax  Expert  System,  each  item  of  the  predicate  data  form 
should  be  represented  by  a  three-element  list  of  the  triple  form:  [Object,  Attribute, 
Value].  Column  3  shows  the  triples  of  the  items.  The  triple  form  is  used  as  the 
actual  input  of  the  IDEFo  Syntax  Expert  System.  The  activity  box  name,  NAME, 
is  translated  into  the  predicate  activitynamefis,  NAME),  which  means  activity  box 
is  named  as  NAME.  The  predicate  NAME(numberJs,  NUMBER)  for  NUMBER 
means  the  number  of  activity  box  NAME  is  NUMBER.  In  the  case  of  INPUT,  it  is 
translated  into  the  predicate  NAME(input.is,  LABEL),  which  means  the  input  of 
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activity  box  NAME  is  LABEL.  Similarly,  in  the  case  of  OUTPUT,  CONTROL,  and 
MECHANISM,  they  are  easily  translated  into  the  predicate  data  forms  as  shown 
in  the  table  5.1.  In  the  case  of  NUMBER  OF  INPUTS,  it  is  translated  into  the 
predicate  NAME(hasJnput-number,  COUNT),  which  means  activity  box  NAME  has 
COUNT  INPUTS.  This  information  is  used  for  checking  the  number  of  inputs  which 
is  limited  and  the  boundary  arrow.  Also,  NUMBER  OF  OUTPUTS,  NUMBER  OF 
CONTROLS,  and  NUMBER  OF  MECHANISMS  are  translated  similarly. 

Boundai  y.  The  type  of  a  boundary  arrow  is  one  of  either  input,  output,  con¬ 
trol,  or  mechanism.  These  are  the  touched  arrows  of  an  activity  box  as  well.  Since 
the  boundary  arrows  should  be  related  to  the  current  IDEF0  diagram  and  an  activ¬ 
ity  box  of  the  parent  IDEF0  diagram,  the  predicate  information  of  the  activity  box 
should  have  been  saved  already.  Table  5.2  shows  the  translation  rules  for  boundary 
arrows.  BOUNDARY  INPUT  in  column  1  is  translated  into  the  predicate  bound- 
aryJnput(is,  LABEL)  in  column  2,  which  means  LABEL  is  a  boundary  input.  The 
triple  [boundaryjnput,  is,  LABEL]  in  column  3  represents  the  actual  data  base  form 
for  the  IDEFo  Syntax  Expert  System.  BOUNDARY  OUTPUT,  BOUNDARY  CON¬ 
TROL,  and  BOUNDARY  MECHANISM  are  translated  similarly  as  shown  in  Table 

5.2.  NUMBER  OF  BOUNDARY  INPUTS  is  translated  into  the  predicate  bound¬ 
ary  Jnput(has.number,  COUNT),  which  means  the  number  of  boundary  inputs  is 
COUNT.  In  the  case  of  NUMBER  OF  BOUNDARY  OUTPUTS,  NUMBER  OF 
BOUNDARY  CONTROLS,  and  NUMBER  OF  BOUNDARY  MECHANISMS,  they 
are  each  translated  as  shown  in  Table  5.2. 

IDEFo  Syntax  Expert  System 

The  detailed  structure  of  the  IDEF0  Syntax  Expert  System  is  shown  in  Figure 

5.3.  Since  the  user  interface  portion  is  contained  in  the  inference  engine  as  discussed 
in  Chapter  IV,  this  is  not  mentioned  in  this  chapter.  Thus,  the  IDEF0  Syntax 
Expert  System  consists  of  three  major  components:  Rule  Base,  Working  Memory, 
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Term 

Predicate 

Triple 

BOUNDARY 

INPUT 

boundary -input 
(is,  LABEL) 

[  boundary -input  , 

is,  LABEL  ] 

BOUNDARY 

OUTPUT 

boundary -output 
(is,  LABEL) 

[  boundary  .output  , 

is,  LABEL  ] 

BOUNDARY 

CONTROL 

boundary-control 
(is,  LABEL) 

[  boundary -control  , 

is,  LABEL  ] 

BOUNDARY 

MECHANISM 

boundary -mechanism 
(is,  LABEL) 

[  boundary -mechanism  , 

is,  LABEL  ] 

NUMBER  OF 

BOUNDARY 

INPUTS 

boundary  input 
(has_number,  COUNT) 

[  boundary  input  , 

hasjnumber,  COUNT  ] 

NUMBER  OF 

BOUNDARY 

OUTPUTS 

boundary  .output 
(has_number,  COUNT) 

[  boundary -output  , 

has_number,  COUNT  ] 

NUMBER  OF 

BOUNDARY 

CONTROLS 

boundary -control 
(has-number,  COUNT) 

[  boundary -control  , 

has_number,  COUNT  ] 

NUMBER  OF 

BOUNDARY 

MECHANISMS 

boundary  .mechanism 

(has-number,  COUNT) 

[  boundary_mechanism  , 

has_number,  COUNT  ] 

Table  5.2.  Translation  Rules  for  Boundary  Arrows 
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Rule  Base 


Figure  5.3.  Structure  of  IDEF0  Syntax  Expert  System 

and  Inference  Engine  as  shown  in  Figure  5.3. 

The  detailed  discussion  of  the  Rule  Base  is  given  in  the  next  section,  Rule 
Base.  The  Working  Memory  (Data  Base)  is  initially  set  up  by  the  predicate  out¬ 
put  of  the  IDEFo  Diagram  Translator.  The  predicate  output  is  a  collection  of  fact 
tripples  discussed  in  the  previous  section,  Translation  Rules.  The  inference  engine, 
BC3,  which  directed  problem-solving  processes  and  acted  as  a  rule  interpreter,  was 
available.  BC3  is  a  shell  for  a  backward  chaining  expert  system.  Since  the  backward 
chaining  strategy  is  good  when  there  are  many  more  facts  than  final  goals,  BC3  is 
suitable  for  use  as  the  inference  engine  of  the  IDEFo  Syntax  Expert  System.  Also, 
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since  BC3  was  originally  used  on  the  Zenth  Z-248  workstations,  in  order  to  run  it 
on  the  Sun  workstations,  BC3  should  be  modified.  The  modified  BC3  is  listed  in 
appendix  F. 

BC3  was  implemented  in  Prolog- 1  which  is  a  dialect  of  many  Prolog  languages 
and  is  for  the  personal  computer.  To  reuse  BC3  with  slight  modification,  Quintus 
Prolog,  which  is  available  on  the  Sun  workstations,  was  selected  to  implement  the 
inference  engine  for  the  ISES. 

Rule  Base 

The  inference  engine  (BC3)  applies  each  element  of  the  rule  base  to  the  solution 
of  the  specific  domain.  The  specific  domain  is  divided  into  twro  categories,  one  for 
an  activity  box  and  the  other  for  the  boundary  arrows  in  any  IDEF0  diagram.  Thus 
the  rule  base  (IDEF0  Syntax)  is  separated  into  two  parts:  Activity  IDEF0  Syntax 
and  Boundary  Arrow  IDEFo  Syntax. 

Activity  IDEFo  Syntax.  The  Activity  IDEFo  Syntax  focuses  on  an  activity  box 
in  any  IDEF0  diagram  as  shown  Figure  5.2.  The  following  list  in  English  sentences 
is  extracted  from  Figure  5.2  for  Activity  IDEFo  Syntax. 

•  An  acti^y  box  must  have  a  name. 

•  An  activity  box  must  have  a  number  except  for  the  top-most  level  activity  box. 

•  An  activity  box  must  have  at  least  a  touched  control  arrow  and  a  touched 
output  arrow. 

•  If  an  activity  box  has  touched  arrows,  the  arrows  must  have  their  arrow  labels. 

•  If  an  activity  box  lies  in  the  top-most  level,  the  box  number  must  be  empty. 

•  If  an  activity  box  is  not  in  the  top-most  level,  the  box  number  must  be  within 
1  to  6. 
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•  In  the  case  of  CONTROL  and  OUTPUT,  the  number  of  touched  arrows  must 
be  within  1  to  5. 

•  In  the  case  of  INPUT  and  MECHANISM,  the  number  of  touched  arrows  must 
be  within  0  to  5. 

Figures  5.4  and  5.5  show  a  more  detailed  Activity  IDEF0  Syntax  according  to  above 
English  sentences. 

Column  1  in  Figure  5.4  and  5.5  shows  the  cases  of  INPUT,  OUTPUT,  and 
NUMBER  in  the  figure  5.2.  In  the  case  CONTROL  and  MECHANISM,  if-then 
rules  are  similar  to  OUTPUT  and  INPUT  respectively.  Column  2  presents  all  the 
diagram  types  which  the  user  could  possibly  draw.  Column  3  shows  if-then  rules 
related  to  the  possible  drawings.  As  shown  in  Figure  5.4,  Activity  IDEFo  Syntax 
focuses  on  whether  NAME,  INPUT,  OUTPUT,  CONTROL,  MECHANISM,  and 
NUMBER  are  correct  or  not.  Thus  the  goals  for  Activity  IDEFo  Syntax  rules  become 
a  list  of  triples  about  NAME,  INPUT,  OUTPUT,  CONTROL,  MECHANISM,  and 
NUMBER. 

Boundary  IDEFo  Syntax.  The  Boundary  IDEFo  Syntax  is  associated  with 
boundary  arrows  of  an  IDEF0  diagram  and  its  parent  IDEF0  diagram.  The  following 
english  sentences  represent  the  Boundary  IDEFo  Syntax. 

•  There  must  be  an  activity  box  in  the  parent  IDEFo  diagram. 

•  The  number  of  input,  output,  control,  or  mechanism  arrow(s)  of  the  parent 
activity  box  must  be  equal  to  that  of  the  boundary  input,  output,  control,  or 
mechanism  arrow(s). 

•  Each  arrow  of  the  parent  activity  box  must  have  its  label. 

•  Each  boundary  arrow  must  have  its  label. 

•  Each  boundary  arrow  label  must  correspond  with  label  of  the  parent  activity 
box  arrow. 
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Case  Diagram 


If-then  rules 


INPUT 

(MECHANISM) 


If  there  is  no  input  arrow  then 
INPUT  is  correct  on  the  activity 
box . 


If  there  is  at  least  a  blank  LABEL 
then  there  is  a  LABEL  error  on  the 
activity  box. 


If  the  number  of  input  arrows  is 
greater  them  5  then  the  number  of 
input  arrows  should  be  reduced. 
Otherwise,  INPUT  is  correct. 


If  there  is  no  output  arrow  then 
there  is  an  OUTPUT  error  on  the 
activity  box. 


If  there  is  at  least  a  blank  LABEL 
then  there  is  a  LABEL  error  on  the 
activity  box. 


If  the  number  of  output  arrows  is 
greater  them  5  that  of  output 
arrows  should  be  reduced. 
Otherwise,  OUTPUT  is  correct. 


If  the  activity  box  is  the  top-most 
level  and  NUMBER  is  empty  then  NUMBER 
of  the  activity  box  should  be  empty. 


If  the  activity  box  is  the  top-most 
level  and  NUMBER  is  not  empty  then 
NUMBER  of  the  activity  box  should 
be  empty. 


If  the  activity  box  is  not  the  top¬ 
most  level  and  NUMBER  is  greater 
than  0  and  less  than  7  then  NUMBER 
of  the  activity  box  is  correct. 
Otherwise,  NUMBER  of  the  activity 
box  is  beyond  the  limitation. 
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Case 

Diagram 

If-then  rules 

NAME 

1 

If  there  is  no  activity  box  name  then 
there  is  a  NAME  error  on  the  activity 
box . 

If  there  is  a  NAME  on  the  activity 
box  then  NAME  is  correct. 

Figure  5.5.  Activity  IDEF0  Syntax(continued) 

•  In  the  case  of  (boundary)  CONTROL  and  (boundary)  OUTPUT,  the  number 
of  arrows  must  be  greater  than  or  equal  to  1  and  less  than  6. 

•  In  the  case  of  (boundary)  INPUT  and  (boundary)  MECHANISM,  the  number 
of  arrows  must  be  within  0  to  5. 

Figure  5.6  represents  the  more  detailed  Boundary  IDEF0  Syntax.  Column  1 
in  Figure  5.6  and  5.7  shows  the  cases  of  Boundary  Input  and  Boundary  Output.  If- 
then  rules  for  Boundary  Mechanism  and  Boundary  Control  are  similar  to  Boundary 
Input  and  Boundary  Output  respectively.  Column  2  shows  the  models  of  a  par¬ 
ent  activity  box  which  is  possibly  drawn  focused  on  INPUT(OUTPUT)  arrow(s). 
Column  3  shows  the  models  of  Boundary  Input(Output)  arrow(s)  which  is  possibly 
drawn.  Column  4  presents  if-then  rules  about  the  Boundary  IDEF0  Syntax.  Bound¬ 
ary  IDEFo  Syntax  focuses  on  whether  the  boundary  arrows  in  any  IDEF0  diagram 
correspond  with  the  arrows  on  the  parent  activity  box.  Thus  the  goals  for  Boundary 
IDEFo  Syntax  rules  is  a  list  of  triples  about  Boundary  Input,  Boundary  Output, 
Boundary  Control,  and  Boundary  Mechanism. 

Software  Test 

The  software  testing  methods  for  IDEFo  Diagram  Translator  and  1DEF0  Syn¬ 
tax  Expert  System  were  performed  using  three  steps:  unit  testing,  integration  test- 
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CASE 


PARENT 


CHILD 


If-then  rules 


PARENT 


THERE  IS  NO 

PARENT  BOX  DON’T  CARE 
INFORMATION. 


DON’T  CARE 


BOUNDARY 

INPUT 

MECHANISM) 


DON’T  CARE 


If  there  is  no  information  about 
the  parent  activity  box 
then  can  not  check. 


If  there  is  at  least  one 
blank  boundary  arrow  LABEL 
then  there  is  a  LABEL 
error. 


If  there  is  at  least  one 
blank  LABEL  on  the  parent 
activity  box  then  parent 
Input  arrow  has  no  LABEL. 


If  the  number  of  Input 
arrows  of  the  parent  box 
is  greater  than  or  less 
than  that  of  the  boundary 
Input  arrows  then  there  is 
an  error  of  the  number  of 
parent  Input  and  boundary 
Input  arrows. 


If  there  is  no  Input  arrow 
of  parent  activity  box  and 
boundary  arrow  then 
boundary  Input  is  correct. 


If  LABELs  of  Input  arrows 
of  the  parent  activity  box 
and  boundary  Input  arrows 
are  all  matched  then 
boundary  Input  is  correct. 


If  there  is  at  least  one 
LABEL  which  is  mismatched 
then  there  is  an  error  of 
mismatched  LABEL. 


If  the  number  of  boundary 
Input  arrows  is  greater 
than  5  then  the  number  of 
those  should  be  reduced. 
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CASE 


PARENT 


CHILD 


If-then  rules 


DON’T  CARE 


BOUNDARY 


OUTPUT 

(CONTROL) 


DON’T  CARE 


If  there  is  at  least  one 
blank  boundary  arrow  LABEL 
then  there  is  a  LABEL 
error. 


If  there  is  at  least  one 
blank  LABEL  on  the  parent 
activity  box  then  parent 
Output  arrow  has  no  LABEL. 


If  there  is  no  boundary 
Output  arrow  then  there 
must  be  at  least  a  boundary 
Output  arrow. 


If  there  is  no  Output  arrow 
then  there  must  be  at  least 
an  Output  arrow  on  parent 
activity  box. 


If  the  number  of  Output 
arrows  of  the  parent  box 
is  greater  than  or  less 
than  that  of  the  boundary 
Output  arrows  then  there  is 
an  error  of  the  number  of 
parent  Output  and  boundary 
Output  arrows. 


If  LABELs  of  Input  arrows 
of  the  parent  activity  box 
and  boundary  Input  arrows 
are  all  matched  then 
boundary  Input  is  correct. 


If  there  is  at  least  one 
LABEL  which  is  mismatched 
then  there  is  an  error  of 
mismatched  LABEL. 


If  the  number  of  boundary 
Output  arrows  is  greater 
than  5  then  the  number  of 
those  should  be  reduced. 
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ing,  and  validation  testing  (12:502).  These  methods  use  the  white  box  testing  meth¬ 
ods  discussed  in  Chapter  IV. 

The  Unit  testing  step  focuses  on  each  module  individually  to  be  sure  that  it 
functions  properly  as  a  unit  (12:502).  The  test  considerations  are  module  interface, 
data  structure,  boundary  conditions,  basis  path  through  the  control  structure,  and 
error  handling  paths  (12:503).  Unit  test  considerations  are  applied  to  IDT  and  ISES 
individually.  For  IDEF0  Diagram  Translator,  IDEFo  diagram  is  prepared.  Predicate 
data  files  are  also  prepared  for  IDEFo  Syntax  Expert  System. 

The  Integration  testing  step  is  applied  to  take  unit-tested  modules  and  con¬ 
struct  a  complete  program  structure  to  ensure  that  the  interfaces  between  modules 
are  correct  (12:507).  Bottom-up  integration  is  used  because  IDEF0  Diagram  Trans¬ 
lator  and  IDEFo  Syntax  Expert  System  are  lower-level  than  SAtool.  First,  testing 
for  IDEFo  Diagram  Translator  was  performed  and  then  the  whole  system  of  SAtool 
was  examined.  Also  testing  of  IDEFo  Syntax  Expert  System  was  applied  separated 
because  ISES  is  separated  with  IDT  and  SAtool. 

The  Validation  testing  step  is  performed  to  provide  final  assurance  that  the 
software  meets  the  mentioned  requirements.  This  focuses  on  the  Are  we  building  the 
light  product?  (12:499).  This  step  was  used  to  examine  whether  the  IDT  produced 
predicate  data  forms  correctly  and  the  ISES  checked  completely  IDEF0  syntax. 

Summary 

This  chapter  described  the  low  level  design  and  implementation  of  IDEFo  Di¬ 
agram  Translator  and  IDEFo  Syntax  Expert  System  based  on  the  requirements  of 
the  tool.  The  translation  rules  and  the  components  of  ISES  are  also  represented. 
Finally,  testing  methodology  applied  in  this  investigation  are  discussed. 
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VI.  Conclusions  and  Recommendations 


Introduction 

The  objective  of  this  thesis  investigation  was  to  design  and  implement  an 
application  of  expert  system  for  checking  IDEFo  syntax  of  IDEF0  diagrams  as  derived 
from  the  SAtool.  This  chapter  presents  the  conclusions  and  directions  for  possible 
future  research. 

Conclusions 

This  investigation  is  classified  into  two  major  categories:  IDEF0  Diagram 
Translator  and  IDEFo  Syntax  Expert  System.  The  work  for  the  IDEFo  Diagram 
Translator  was  performed  in  two  phases.  During  the  first  phase,  the  formulation 
of  graphical  features  of  the  IDEF0  diagram  was  derived  through  predicate  calculus 
representation,  since  the  predicate  calculus  is  a  convenient  representation  for  facts 
and  rules  of  inference.  The  formal  definition  of  the  IDEF0  graphical  features  does 
not  have  completeness  but  consistency  because  the  IDEFo  graphical  language  con¬ 
tains  semantic  meanings.  The  second  phase  included  the  development  of  the  IDEF0 
Diagram  Translator  which  translates  the  IDEFo  graphical  features  in  the  IDEFo 
diagram  into  a  set  of  predicate  data  forms.  The  predicate  data  forms  focus  on  an  ac¬ 
tivity  box  and  associated  arrows  and  on  the  boundary  arrows  in  any  IDEF0  diagram. 
Predicate  data  forms  become  the  data  base  (working  memory)  for  the  IDEFo  Syntax- 
Expert  System.  The  IDEF0  Syntax  Expert  System  consists  of  the  inference  engine, 
the  knowledge  base,  the  data  base,  and  the  user  interface.  The  inference  engine 
applies  the  knowledge  to  the  solution  of  a  specific  domain.  To  check  IDEF0  syn¬ 
tax  in  any  IDEFo  diagram,  the  backward  chaining  control  strategy  is  useful  because 
there  are  many  more  facts  than  final  goals.  The  knowledge  base  was  identified  with 
emphasis  on  the  activity  box  and  on  the  boundary  arrows  in  any  IDEF0  diagram. 
The  knowledge  base  structure  is  easy  to  extend  to  new  IDEFo  syntax  rules  indepen- 
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dently  of  other  rules  and  to  change  independently  of  other  rules.  Each  segment  of 
the  knowledge  base  defines  a  small  and  relatively  independent  piece  of  knowledge. 

Recommendations 

Based  on  the  results  of  this  study  and  the  observations  made  during  it,  this  sec¬ 
tion  presents  some  recommendations  for  future  research  which  could  lead  to  enhance 
the  capability  of  the  ISES. 

Activity  Currently,  the  tool  can  check  the  IDEF0  syntax  of  only  a  single  ac¬ 
tivity  box  and  associated  arrows  in  any  IDEFo  diagrams.  The  relationship  among 
activity  boxes  and  arrows  in  composite  IDEF0  diagrams  could  be  defined  to  enhance¬ 
ments  of  the  ISES’s  capability.  For  example, 

•  The  name  of  an  activity  box  should  not  be  the  same  as  that  of  other  activity 
boxes  in  any  IDEF0  diagrams. 

•  The  number  of  an  activity  box  should  not  be  the  same  as  that  of  other  activity 
boxes  in  any  IDEF0  diagram. 

•  The  line  label  on  an  activity  box  should  not  be  the  same  as  that  on  other 
activity  boxes  in  any  IDEF0  diagram. 

Boundary  Since  the  ISES  can  check  syntax  of  the  boundary  arrows  except  the 
tunnel  arrow,  add  the  IDEFo  syntax  rules  about  the  tunnel  arrow.  This  issue  implies 
IDEFo  syntax  check  of  the  multilevel  IDEFo  diagrams. 

Integrate  the  translation  process  with  the  syntax  checking  process  to  be  more 
user  friendly.  This  issue  needs  to  address  how  the  C  language  should  interface  with 
Quintus  Prolog  or  some  other  prolog. 

Apply  the  structure  of  the  knowledge- based  IDEFo  syntax  system  to  incor¬ 
porate  the  design  knowledge  of  a  specific  software  application.  Since  the  design 
knowledge  provides  a  means  of  abstracting  software  design  into  resuable  modules. 
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the  design  knowledge  using  the  IDEFo  methodology  can  be  reused  for  a  similar  soft¬ 
ware  design.  The  know  ledge- based  IDEF0  syntax  system  uses  IDEF0  model  segments 
to  represent  design  modules  which  are  combined  and  refined  to  generate  an  entire 
IDEFo  model. 

Summary 

This  chapter  presented  the  conclusions  derived  from  the  design  and  imple¬ 
mentation  of  an  application  of  expert  system  for  checking  IDEFo  syntax  of  IDEFo 
diagrams  drawn  from  the  SAtool  and  the  recommendations  for  future  research. 
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Appendix  A.  Requirements  Analysis  Diagrams 


This  appendix  contains  the  requirements  analysis  IDEF0  diagrams  for  the 
IDEF0  Diagram  Translator.  These  diagrams  are  not  exactly  one-to-one  correspon¬ 
dence  with  the  implementation  modules,  but  are  close. 
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A-0  Provide  SAtool 


Abstract:  Provide  SAtool  provides  a  means  of  mechanism  by 
which  the  user  is  able  to  draw  Activity  IDEFO  Diagrams. 
From  these  diagrams,  Facing  Page  Text  and  Data  Dictionaries 
for  Activities  and  Data  and  Predicate  Data  forms  are 
generated . 


Figure  A.l.  Provide  SAtool  (Node  A-0) 
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AO  Provide  SAtool 

Abstract:  Provide  SAtool  provides  the  user  a  mechanism  by 

which  the  user  is  able  to  draw  Activity  IDEFO  Diagrams. 
From  these  diagrams,  Facing  Page  Text,  Data  Dictionaries  for 
Activities  and  Data,  and  Predicate  Data  forms  are  generated. 

A1  Provide  SA  Editor  provides  a  means  of  drawing 

Activity  IDEFO  Diagrams.  From  these  diagrams,  Facing  Page 
Text  and  Data  Dictionaries  for  Activities  and  Data  are 
generated . 

A2  Translate  Diagram  provides  a  means  of  translating 
IDEFO  Diagrams  into  Predicate  Data  Forms. 


NODE :  T 

ITLE : 

Provide  SAtool 

NUMBER:  C-2 

A0 

...  ..  .  _  .  --  - — i 

Figure  A. 2.  Provide  SAtool  (Node  AO) 


A2  Translate  Diagram 


Abstract:  Translate  Diagram  provides  the  user  a  means  of 
translating  IDEFO  Diagrams  into  Predicate  Data  Forms. 

A21  Translate  Activity  provides  a  means  of  translating 
an  activity  box  in  any  IDEFO  Diagrams  into  a  set  of  predicate 
data  forms  through  the  translation  rules  of  the  activity  box. 

A22  Translate  Boundary  provides  a  means  of  translating 
the  boundary  arrows  in  any  IDEFO  Diagrams  into  Predicate  data 
forms  through  the  translation  rules  of  the  boundary  arrows. 

A23  Save  Diagram  provides  a  means  of  translating  the 
IDEFO  Diagram  into  a  set  of  the  predicate  data  forms  and 
saving  it  into  a  file  which  user  specifies  interactively. 


A21  Translate  Activity 

Abstract:  Translate  Activity  provides  a  means  of  translating 

an  activity  box  in  any  IDEFO  Diagrams  into  a  set  of  predicate 
data  forms  through  the  translation  rules  of  the  activity  box. 

A211  'find  clicked  box'  module  provides  a  means  of 
finding  an  activity  box  which  user  specifies  using  the  mouse 
in  the  IDEFO  diagram. 

A212  'save  header  info'  module  provides  a  means  of 
saving  the  head  information  of  the  IDEFO  diagram  which  is 
needed  to  check  Boundary  IDEFO  Syntax. 

A213  'save  box  arrow  info'  module  provides  a  means  of 
grasping  the  information  of  the  activity  box  and  the  arrows 
which  are  attatched  on  the  activity  box. 


Figure  A. 4.  Translate  Activity  (Node  A21) 
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A213  save  box  arrow  info 

Abstract:  'save  box  arrow  info'  module  provides  a  means  of 

grasping  the  information  of  the  activity  box  and  the  arrows 
which  are  attatched  on  the  activity  box. 

A2131  'get  box  info'  module  provides  a  means  of 
holding  and  saving  the  activity  box  name  and  the  number  into 
a  file  in  forms  of  predicate  using  the  translation  rules. 

A2132  'get  arrow  info'  module  provides  the  information 
of  the  arrows  which  are  touched  an  activity  box  in  forms  of 
predicate . 


AUTHOR: 


PROJECT 


Intask  Kim 


DATE  .-30/81/ 90  (READER 


box  structure  Cl  C2 

Translation  Rules 


IDEF0  Diagram 

II  1 


get  box 
Info 


box  arrow  Info 


get 

arrow  _ J 

inf0  arrow  Info 

2 


ITUE:  save  box  arrow  Info 


NUMBER:  C  -5 


Figure  A. 5.  Save  Box  Arrow  Info  (Node  A213) 


A2132  get  arrow  info 


ADstract:  'get  arrow  info'  module  provides  the  information 

of  the  arrows  which  are  touched  an  activity  box  in  forms  of 
predicate . 

A21321  'get  inputs'  module  provides  a  means  of 
grasping  the  predicate  data  forms  of  all  kind  of  input  arrows 
which  are  touched  on  an  activity  box. 

A21322  'get  outputs'  module  provides  a  means  of 
grasping  the  predicate  data  forms  of  all  kind  of  output  arrows 
which  are  touched  on  an  activity  box. 

A21323  'get  controls'  module  provides  a  means  of 
grasping  the  predicate  data  forms  of  all  kind  of  control  arrows 
which  are  touched  on  an  activity  box. 

A21324  'get  mechanisms'  module  provides  a  means  of 
grasping  the  predicate  data  forms  of  all  kind  of  mechanism  arrows 
which  are  touched  on  an  activity  box. 


AUTHOR:  Intaek  Kim 

DATE:B8/M/90 

READER 

— 

PROJECT:  SAtool 

REV: 1.0 

DATE 

— 

01 


NODE: 

A2132 


[TITLE:  get  arrow  Info 


NUMBER:  C-6 


Figure  A. 6.  Get  Arrow  Info  (Node  A2132) 
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A21321  get  inputs 

Abstract:  'get  inputs'  module  provides  a  means  of  grasping 

the  predicate  data  forms  of  all  kind  of  input  arrows  which 
are  touched  on  an  activity  box. 

A213211  'get  single  head  input'  module  provides  a  means 
grasping  the  single  headed  input  arrows'  information  translated 
in  the  predicate  data  forms  which  are  touched  on  an  activity 
box. 


A213212  'get  double  head  input'  module  provides  a  means  of 
grasping  the  predicate  data  forms  of  the  double  headed  input  arrows 
which  are  touched  on  an  activity  box. 

A213213  'get  doublehead  in/w  slash'  module  provides  a 
means  of  grasping  the  predicate  data  forms  of  the  double  headed 
input  arrows  with  the  slash  which  are  touched  on  an  activity  box. 


AUTHOR: 

Intaek  Ktm 

DATE:  30/01/98 

READER 

PROJECT: 

SA tool 

REV: 1.0 

DATE 

J 

01 


'NOOE  t 
A21321 


[TITLE:  get  Inputs 


NUMBER:  C-7 


Figure  A. 7.  Get  Inputs  (Node  A21321) 
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A21322  get  outputs 


Abstract:  'get  outputs'  module  provides  a  means  of 

grasping  the  predicate  data  forms  of  all  kind  of  output  arrows 
which  are  touched  on  an  activity  box. 

A213221  'get  single  head  output'  module  provides  a  means 
of  grasping  the  predicate  data  forms  of  the  output  arrows 
with  a  single  head  which  are  touched  on  an  activity  box. 

A213222  'get  double  head  out/con'  module  provides  a  means 
of  grasping  the  predicate  data  forms  of  the  output  arrows 

with  the  double  head  one  for  the  output  and  the  other  for  the 
control  arrow  of  another  box. 

A213223  'get  double  head  out/in'  module  provides  a  means 
of  grasping  the  predicate  data  forms  of  the  output  arrows 

with  the  double  head  one  for  the  output  and  the  other  for  the 
input  arrow  of  another  box. 

A213224  'get  double  head  output'  module  provides  a  means 
of  grasping  the  predicate  data  forms  of  the  output  arrow 

which  leaves  the  right  side  of  an  activity  box  and  there  is  a 
double  head. 


Figure  A.S.  Get  Outputs  (Node  A21322) 
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A21323  get  controls 

Abstract:  'get  controls'  module  provides  a  means  of 

grasping  the  predicate  data  forms  of  all  kind  of  control 
arrows  which  are  touched  on  an  activity  box. 

A213231  'get  single  head  control'  module  provides 
a  means  of  gr<  sping  the  predicate  data  forms  of  the  control 
line  which  cones  to  the  upper  side  of  an  activity  box  and 
there  is  a  single  headed  arrow. 

A213232  'get  double  head  control'  module  provides 
a  means  of  grasping  the  predicate  data  forms  of  the  control 
line  which  comes  to  the  upper  side  of  an  activity  box  and 
there  is  a  double  headed  arrow. 

A213233  'get  double  head  con/slash'  module  provides 
a  means  of  grasping  the  predicate  data  forms  of  the  control 
line  which  comes  to  the  upper  side  of  an  activity  box  and 
there  is  a  double  headed  arrow  with  a  slash. 


Figure  A. 9.  Get  Controls  (Node  A21323) 
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A22  Translate  Boundary 

Abstract:  Translate  Boundary  provides  a  means  of  translating 

the  boundary  arrows  in  any  IDEFO  Diagrams  into  Predicate  data 
forms  through  the  translation  rules  of  the  boundary  arrows. 

A221  'get  parent  box'  module  provides  a  means  of 
grasping  the  predicates  for  the  parent  activity  box  and 
producing  the  parent  information. 

A222  'save  null  boundary'  module  provides  a  means  of 
grasping  the  predicates  if  there  is  no  the  boundary  arrow  in 
according  with  the  input,  output,  control,  or  mechanism  of 
the  IDEFO  diagram. 

A223  'save  boundary  info'  module  provides  a  means  of 
grasping  the  predicates  of  the  boundary  arrows  if  there  is  at 
least  one  boundary  arrow  in  the  IDEFO  diagram. 


AUTHOR:  Intaek  Kim 


PROJECT:  SAtool 


DATE  :30/01/SB  READER 


REV:  1.0  DATE 
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- - r - »  ent  box  £ - 
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Boundary  Predicates 


save  nu  null  boundary 
1 1  bounda  - 


save  bo  J 

undary  in  _ 

f0  boundary  info 
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ITLE:  Translate  Boundary 
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A223  save  boundary  info 


Abstract:  'save  boundary  info'  module  provides  a  means  of 

grasping  the  predicates  of  the  boundary  arrows  if  there  is  at 
least  one  boundary  arrow  in  the  IDEFO  diagram. 

A2231  'search  boundary  lines'  module  provides  a  means 
of  searching  for  the  boundary  lines  for  the  IDEFO  diagram  and 
producing  a  linked  list  of  line  structure  as  the  output. 

A2232  'get  boundary  line  labels'  module  provides  a 

means  of  grasping  the  line  labels  of  the  boundary  lines  in  the 
IDEFO  diagram. 


Figure  A .  1 1 .  Save  Boundary  Info  (Node  A223) 
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A23  Save  Diagram 

Abstract:  Save  Diagram  provides  a  means  of  translating  the 

IDEFO  Diagram  into  a  set  of  the  predicate  data  forms  and  saving 
it  into  a  file  which  user  specifies  interactively. 

A231  The  function  of  'get  file  name'  module  is  to  get 

a  file  name  from  the  user  in  order  to  save  the  predicate  data 
forms  for  the  IDEFO  diagram  into  it. 

A232  The  function  of  'store  predicates'  module  is  to 
save  the  predicates  for  the  IDEFO  diagram  into  a  file  which  the 
user  specifies. 


Figure  A.  12.  Save  Diagram  (Node  A23) 
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A232  store  predicates 

Abstract:  The  function  of  'store  predicates'  module  is  to 

save  the  predicates  for  the  IDEFO  diagram  into  a  file  which  the 
user  specifies. 

A2321  'save  header  info'  has  the  same  function  of  module 
A212.  See  A212  description. 

A2322  'traverse  boxes'  module  function  is  to  traversing 
every  boxes  in  the  IDEFO  diagram. 
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A2322  traverse  boxes 


Abstract:  'traverse  boxes'  module  function  is  to  traversing 

every  boxes  in  the  IDEFO  diagram. 

A23221  'get  a  box'  module  function  is  to  get  the 
information  for  an  activity  box  in  the  IDEFO  diagram. 

A23222  'save  box  arrow  info'  module  function  is  the 
same  as  module  A213. 


A23223  'get  boxes  arrows'  module  function  is 
the  predicates  of  every  activity  box  and  arrow  in  the 
diagram. 


to  gether 
IDEFO 


AUTHOR:  Intaek  Kim 

DATE: 08/05/98 

READER 

PROJECT:  SAtool 

REV: 1.0 

DATE 

NODE: 

TITLE:  traverse  boxes 

NUMBER:  C-14 

A2322 

Figure  A.  14.  Traverse  Boxes  (Node  A2322) 


Appendix  B.  Structured  Chart 


This  appendix  contains  the  detailed  design  structure  charts  for  the  IDEFo 
Diagram  Translator  implementation.  The  detailed  design  is  concerned  with  the 
requirements  analysis  diagrams  in  appendix  A.  There  is  a  close,  but  not  exactly 
one-to-one,  correspondence  between  the  design  modules  and  the  implementation 
modules. 
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Figure  B.l.  Provide  SAtool(Module  1.0) 
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Appendix  C.  Data  Structures  of  SAtool 


Introduction 

The  purpose  of  this  appendix  is  to  discuss  of  the  Data  Structures  of  SAtool 
developed  by  Steven  E.  Johnson  (9).  A  discussion  of  the  data  structures  of  the 
SAtool  is  needed  because  this  thesis  work  should  interface  with  the  SAtool  and  use 
the  1DEF0  diagrams  and  files  generated  by  the  SAtool.  The  SAtool  allows  users  to 
interactively  create  and  edit  IDEFo  diagrams  and  to  automatically  produce  the  data 
dictionary  information. 

Data  Structure 

Five  primary  data  structures  were  designed  to  hold  all  the  graphics  and  data 
dictionary  information:  the  box  structure,  the  line  structure,  the  squiggle  line  struc¬ 
ture.  the  header  structure,  and  the  footnote  structure  (9:4-11  -  4-14). 

The  box  structure  contains  the  information  which  is  necessary  to  locate,  name, 
and  enumerate  activity  boxes  (9:4-11).  The  activity  boxes  in  the  IDEF0  diagram  are 
hooked  by  the  linked  list.  The  box  structure  uses  two  C  pointers  one  for  the  next  box 
structure  and  the  other  for  pointing  an  activity  data  dictionary  structure  (9:4-11). 

The  line  structure  consists  of  the  fields  w’hich  are  necessary  to  lacate,  label, 
draw  the  lines,  enumerate  the  lines  to  identify  them,  store  the  ICOM  labels,  and  store 
the  TO/FROM  ALL  labels  (9:4-11  -  4-12).  The  line  structure  uses  two  numbers  to 
identify  the  type  of  each  end  of  the  line  (ie.  arrowhead,  tunnel,  dot,  turn  right,  or 
branch  left,  etc.)  and  uses  C  pointers  to  store  the  lines  in  binary  trees  with  the  root 
nodes  (9:4-12).  Figure  C.l  shows  four  groups  of  the  lines  and  the  corresponding 
linked  list  structure  is  presented  in  Figure  C.2  (9:4-12  -  4:13).  The  tree  arrangement 
in  Figure  A. 2  maps  to  how  the  line  segments  actually  connect  to  one  another  and 
C  pointer  supports  the  simple  recursive  functions  used  to  traverse  the  binary  trees 
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Figure  C.l.  Example  Group  of  lines  (9:4-12) 

(9:4-12).  The  line  structure  uses  another  C  pointer  to  point  to  a  data  divtionary 
information  for  a  data  element. 

The  squiggle  line  structure  contains  the  information  which  is  necessary  to  locate 
and  to  identify  each  squiggle  line  in  the  IDEF0  diagram  (9:4-13).  The  squiggle  line 
structure  uses  a  C  pointer  to  store  the  squiggle  lines  for  a  particular  IDEFo  diagram 
in  a  single  linked  list  (9:4-13  -  4-14). 

The  header  structure  consists  of  seven  fields  which  are  needed  to  draw,  locate, 
and  classify  AUTHOR,  DATE,  PROJECT,  REV,  NODE,  TITLE,  and  NUMBER 
of  an  IDEFo  diagram(9:4-14  -  4-15).  A  single  C  pointer  is  used  to  save  the  header 
information  since  each  IDEFo  diagram  only  has  one  header  (9:4-14). 

Finally,  the  footnote  structure  contains  the  information  which  is  needed  to 
draw,  locate  and  identify  a  matched  pair  of  footnote  labels  (9:4-14).  A  C  pointer  is 
defined  to  point  another  footnote  structure  since  the  footnote  structures  for  a  IDEFo 
diagram  are  stored  in  a  single  linked  list  (9:4-14). 
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Figure  C.2.  The  Linked  List  for  Lines  (9:4-13) 

Sum  rnary 

In  this  appendix,  the  data  structure  of  the  SAtool  which  is  necessary  to  perform 
this  thesis  investigation  was  addressed  from  Johnson’s  effort.  This  information  was 
used  throughout  this  thesis  effort. 
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Appendix  D.  User’s  Manual 


User’s  Manual  introduces  the  basics  of  the  ISES.  The  purpose  of  this 
ual  provides  a  broad  understanding  of  the  ISES’s  operation,  then  provides  a 
detailed  example  for  learning  to  use  the  ISES. 


man- 

more 
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Introduction 


The  IDEF0  Syntax  Expert  System(ISES)  is  an  interactive  syntax  check  system. 
It  provides  a  means  for  checking  IDEFo  syntax  in  any  IDEF0  diagrams  drawn  by 
SAtool  and,  producing  error  messages,  error  recovery,  and  editing  suggestions.  ISES 
allows  the  user  to  select  a  menu  for  drawing  an  IDEFo  diagram  and  checking  IDEF0 
syntax.  The  functions  of  the  main  menus  include: 

•  RECALL  DGM  -  read  in  a  previously  saved  IDEF0  diagram. 

•  EDIT  DGM  -  edit  an  IDEFo  diagram  according  to  its  attribute  menus. 

•  EDIT  DD  -  edit  a  data  dictionary. 

•  EDIT  FPT  -  edit  a  facing  page  text. 

•  MISC  FUNC  -  save  a  diagram,  change  directory,  exit  SAtool,  etc. 

•  SAVE  DGM  -  save  a  graphics  information  and  a  data  dictionary  information. 

•  CHECK  S}'NTAX  -  check  IDEF0  syntax. 

The  first  six  menus  are  for  drawing  IDEFo  diagrams,  generating  Data  Dictionary 
information,  and  Facing  Page  Text  and  the  last  one  is  for  ISES  to  check  IDEF0 
syntax.  A  detailed  guide  for  drawing  IDEFo  diagram  is  available  in  the  user’s  man¬ 
ual  of  Johnson’s  thesis  (9).  This  User’s  Manual  focuses  on  the  CHECK  SYNTAX 
part.  ISES  runs  on  Sun3™  and  Suni™  workstations  using  the  SunOSrA/  1  and  the 
SunViewTA/  window-based  environment.  This  manual  explains  how  CHECK  SYN¬ 
TAX  can  be  used  to  check  IDEF0  syntax.  Some  previous  familiarity  with  IDEF0 
syntax  and  SAtool  is  required.  Though  not  necessary,  some  familiarity  with  SunOS 
and  SunView  is  helpful.  Users  should  be  thoroughly  familiar  with  the  concepts 
presented  in  this  manual  before  using  ISES. 

‘SunOS™  is  a  trademark  of  Sun  Microsystems,  Inc. 
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The  Mouse 


To  move  the  cursor,  place  the  mouse  on  its  pad  and  move  it  in  the  desired 
direction.  During  the  execution  of  SAtooi,  User  is  required  to  click  the  mouse  button. 
All  mouse  button  inputs  should  be  clicked  on  the  proper  location  in  IDEF0  diagram, 
otherwise,  the  mouse  button  inputs  are  ignored. 

•  Right  Button 

The  right  button  is  used  almost  to  abort  operation  of  menu  selected. 

•  Middle  Button 

The  middle  button  is  used  to  exit  SAtooi  (see  Exit  SAtooi). 

•  Left  Button 

The  left  mouse  button  is  used  to  select  one  of  menus  and  to  start  a  menu 
operation. 

How  to  draw  lines  well 

Almost  of  the  unnoticed  errors  are  produced  in  the  field  of  drawing  lines.  They 
provide  a  menas  of  generating  unsuitable  predicate  data  forms. 

1.  Boundary  lines 

•  All  boundary  lines  should  have  their  ICOM  labels. 

•  All  arrows  of  Inputs,  Mechanisms,  and  Controls  must  be  touched  on  any 
box.  The  segment  of  lines  inside  an  activity  box  is  truncated  automati¬ 
cally. 

•  All  output  lines  should  be  begun  inside  an  activity  box. 

2.  Inter  activity  box  lines 

Every  starting  and  ending  point  of  the  line  segments  should  be  begun  and 
ended  inside  an  activity  box  excepting  the  branch,  join  lines,  and  TO/FROM 


Getting  Started 

Set  your  UNIX  path  variable  to  include  the  ISES  executable  directory. 

1.  Enter  ”suntools” 

enter  SunView  and  SunWindow  environment. 

2.  Enter  ”SAtool” 

enter  the  IDEF0  Diagram  Translator  environment. 

3.  The  Main  Menu 

Menus  are  displayed  as  the  oval  forms  on  the  screen. 

Move  the  cursor  to  one  the  following  choices  to  select: 

•  RECALL  DGM 

•  EDIT  DGM 

•  EDIT  DD 

•  EDIT  FPT 

•  MISC  FUNC 

•  SAVE  DGM 

•  CHECK  SYNTAX 

4.  IDEFq  diagram 

By  selecting  one  of  the  first  five  menus,  The  user  is  able  to  draw  a  new  IDEF0 
diagram  or  update  the  previous  IDEFo  diagram. 

5.  IDEFq  Syntax 

After  drawing  an  IDEFo  diagram,  select  CHECK  SYNTAX  oval  by  clicking  the 
left  mouse  button  on  it.  Now,  three  attribute  submenus  are  displayed  as  the 
rectangular  forms.  Move  the  cursor  to  on.  of  the  following  choices  to  select: 

•  Activity 
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•  Boundary 

•  Save(.pro) 

IDEFo  syntax  consists  of  Activity  and  Boundary  IDEFo  syntax. 

6.  Activity  IDEFq  syntax 

After  clicking  the  left  button  on  Activity  rectangular  box  of  the  submenus, 

(a)  Move  the  cursor  inside  a  box  to  be  checked  and  click  the  left  mouse  button 
(Right  -  ABORT). 

(b)  Enter  the  Prolog  environment  using  another  window. 

7.  Boundary  IDEFo  Syntax 

NOTE:  User  must  have  the  predicate  file  of  the  parent  IDEFq  diagram. 

(a)  After  clicking  the  left  button  on  Boundary  rectangular  box  of  menus, 

(b)  move  the  cursor  inside  the  input  window  and  enter  the  file  name  with  the 
parent  activity  box  information  (Right-ABORT). 

(c)  Enter  the  Prolog  environment  using  another  window. 

8.  Saving  the  predicate  file 

(a)  After  clicking  the  left  mouse  button  on  ”save(.pro)”  rectangular  box  of 
menus, 

(b)  move  the  cursor  inside  the  input  window,  and  then  enter  the  file  name 
for  the  current  IDEFo  diagram.  This  file  is  a  set  of  predicate  data  forms 
translated  from  the  graphical  information  in  the  IDEF0  diagram.  It  is 
used  to  check  Boundary  IDEF0  syntax.  The  extension  of  the  predicate 
file  is  a  .pro. 

9.  Prolog  Environment 

Enter  ” prolog This  invokes  the  Prolog  interpreter. 
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(a)  Enter  ”[’ISES -  consult  ISES. 

Now,  the  following  message  is  showed: 


/ft***********************************************************/ 


/*  */ 

/*  WELCOME  TO  IDEFO  SYNTAX  EXPERT  SYSTEMS  */ 

/*  */ 

/*  I.  Type  start.  to  begin  a  new  session.  */ 

/*  II.  Answer  all  questions  using  lower  case  and  ending  with*/ 
/*  a  period.  */ 

/*  */ 

/*  III.  Type  halt.  to  exit  Prolog  session.  */ 

/*  */ 


/*************************************************************/ 


(b)  Enter  "start.”  to  begin  checking  IDEFo  syntax  of  a  clicked  box  in  the 
current  IDEF0  diagram.  Then,  the  message: 

Question:  Do  you  want  verbose  operation(y./n.)?  is  displayed.  Enter  ”y.” 
or  ”n.”.  In  sace  of  ”y.  ”,  the  list  of  rules  fired  are  shown  and  in  case  of 
”n.’\  only  the  IDEFo  syntax  messages  are  displayed.  (See  Examples). 

(c)  After  then,  the  following  message  is  shown  on  the  screen: 


Question:  Do  you  wish  to  check  ACTIVITY  BOX,  BOUNDARY  ARROWS 
or  to  have  HELP  MESSAGES  ? 

To  check  ACTIVITY  BOX  ->  Enter  a. 

To  check  BOUNDARY  ARROWS  ->  Enter  b. 

To  have  HELP  MESSAGES  ->  Enter  h. 

Choice  : 

If  checking  Activity  IDEF$_{0}$  syntax,  enter  "a.", 
checking  Boundary  IDEF$_{0}$  syntax,  enter  "b.",  or 
wishing  Help  Message,  enter  "h.". 
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10.  IDEFq  Syntax  Message 

According  to  selection  above  description,  the  resulting  messages  of  the  IDEFo 
syntax  checking  procedure  are  displayed  (see  Examples). 

1 1 .  Trace 

The  message,  Question:  Do  you  wish  to  see  how  this  answer  was  arrived  at 
(y./n.)?  is  followed  by  the  resulting  messages.  Enter  "y.  ”  or  ”n.  ”y.”  means 

that  the  trace  regarding  the  IDEFo  syntax  message  derived  is  displayed  and 
”n.”  skips  (see  Examples). 

12.  Save  Working  Memory 

Then,  the  message,  Question:  Do  you  wish  to  save  the  current  working  memory 
in  a  file  (y./n.)?  is  displayed.  Enter  ”y.”  or  ”n.”.  In  the  case  of  ”y.”,  the 
current  working  memory  is  saved  in  a  file  which  is  specified  by  the  user  and  of 
”n.”,  the  current  working  memory  is  erased  automatically. 

13.  Exit  Prolog  Environment 

By  entering  ’’halt.”  or  *’ Ctrl  c”,  prolog  session  is  ended. 

14.  Exit  SAtool 

To  exit  SAtool,  click  the  left  mouse  button  on  the  ”MISC  FUNC”  oval  of  the 
main  menus.  And  then  click  the  left  mouse  button  on  the  ’’QUIT”  under  the 
”MISC  FUNC”  oval.  Finally,  click  the  middle  button  of  the  mouse. 
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Examples 

This  section  presents  the  actual  demonstrations  for  checking  process  of  the 
correct  IDEF0  diagram,  however,  the  checking  process  about  the  IDEFo  diagram 
with  errors  is  the  same  as  the  correct  case. 
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ares>  prolog 

Quintus  Prolog  Release  2.4.2  (Sun-4,  SunOS  4.0) 

Copyright  (C)  1988,  Quintus  Computer  Systems,  Inc.  All  rights  reserved. 
1310  Villa  Street,  Mountain  View,  California  (415)  965-7700 

I  ?-  C’lSES'] . 

[consulting  /usr2/eng/ikim/SAtoolExpert/ISES. . .] 

/*************************************************************/ 


/*  */ 

/*  WELCOME  TO  IDEFO  SYNTAX  EXPERT  SYSTEMS  */ 

/*  */ 

/*  I.  Type  start.  to  begin  a  new  session.  */ 

/*  */ 

/*  II.  Answer  all  questions  using  lower  case,  ending  with  */ 
/*  a  period.  */ 

/*  */ 

/*  III.  Type  halt.  to  exit  prolog  session.  */ 

/*  */ 


/*************************************************************/ 
[ISES  consulted  1.367  sec  19,008  bytes] 
yes 

I  ?-  start. 

Question:  Do  you  want  verbose  operation(y./n.)?  n. 


Question:  Do  you  wish  to  check  ACTIVITY  BOX,  BOUNDARY  ARROWS 
or  to  have  HELP  MESSAGES  ? 

To  check  ACTIVITY  BOX  ->  Enter  a. 

To  check  BOUNDARY  ARROWS  ->  Enter  b. 

To  have  HELP  MESSAGE  ->  Enter  h. 

Choice  :  a. 


/***************  IDEFO  Syntax  Messages  ***************/ 
Name  — >  CORRECT:  Activity  Name  is  OK. 

Input  — >  CORRECT:  Input  is  OK. 

Output  — >  CORRECT:  Output  is  OK. 
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Control  — >  CORRECT:  Control  is  OK. 

Mechanism  — >  CORRECT:  Mechanism  is  OK. 

Number  — >  CORRECT:  Activity  number  is  OK. 

This  activity  must  be  the  top  most  level  box. 


Question:  Do  you  wish  to  see  how  this  answer 
was  arrived  at(y./n.)?  n. 

/*****************!!!  WARNING  •!!************************/ 
/*  After  this  session,  all  working  memory  elements  will  */ 
/*  be  erased  except  for  elements  being  protected  by  */ 
/*  keep  statements  in  the  knowledge  base.  */ 

/********************************************************/ 

Question:  Do  you  wish  to  save  the  current  working  memory 
in  a  file(y./n.)?  n. 
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/*************************************+***********************/ 


/*  */ 

/*  WELCOME  TO  IDEFO  SYNTAX  EXPERT  SYSTEMS  */ 

/*  */ 

l*  I.  Type  start.  to  begin  a  new  session.  */ 

/*  */ 

/*  II.  Answer  all  questions  using  lower  case,  ending  with  */ 
/*  a  period.  */ 

/*  */ 

/*  III.  Type  halt.  to  exit  prolog  session.  */ 

/*  */ 


******************************************* *****************/ 


yes 

I  ?-  start. 

Question:  Co  you  want  verbose  operation(y./n.)?  y. 

Question:  Do  you  wish  to  check  ACTIVITY  BOX,  BOUNDARY  ARROWS 
or  to  have  HELP  MESSAGES  ? 

To  check  ACTIVITY  BOX  ->  Enter  a. 

To  check  BOUNDARY  ARROWS  ->  Enter  b. 

To  have  HELP  MESSAGE  ->  Enter  h. 

Choice  :  a. 


/***************  IDEFO  Syntax  Messages  ***************/ 

Trying  rulel::  [Name,  ,  — >  ERROR:  No  Activity  Name. 

Each  box  must  have  an  activity  name] 

Trying  rule2::  [Name,  ,  -->  CORRECT:  Activity  Name  is  OK] 

Proved  rule2::  [Name,  ,  — >  CORRECT:  Activity  Name  is  OK] 

Name  — >  CORRECT:  Activity  Name  is  OK. 

Trying  rule3::  [Input,  ,  — >  CORRECT:  No  Input  Arrows,  however, 

Input  is  OK] 

Trying  rule4::  [Input,  ,  -->  ERROR:  No  Input  Label 

Each  Input  arrow  must  have  an  input  label] 

Trying  rule5::  [Input,  ,  — >  RECOMMEND: 

You  would  better  reduce  the  number  of  Input  arrows 
from  0  to  5] 

Trying  rule6::  [Input,  ,  — >  CORRECT:  Input  is  OK] 

Proved  rule6::  [Input,  ,  — >  CORRECT:  Input  is  OK] 
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Input  — >  CORRECT:  Input  is  OK. 

Trying  rule7::  [Output,  ,  — >  ERROR:  You  should  have  at  least 

one  output  arrow] 

Trying  rule8::  [Output,  ,  -->  ERROR:  No  Output  Label. 

Each  Output  Arrow  should  have  an  output  Label] 
Trying  rule9::  [Output,  ,  — >  RECOMMEND: 

You  would  better  reduce  the  number  of  Output  arrows 
from  1  to  5] 

Trying  rulelO::  [Output,  ,  -->  CORRECT:  Output  is  OK] 

Proved  rulelO::  [Output,  ,  -->  CORRECT:  Output  is  OK] 


Output  — > 

Trying  rulell : : 

Trying  rulel2:: 

Trying  rulel3: : 

Trying  rulel4:: 
Proved  rule!4: : 


CORRECT:  Output  is  OK. 

[Control,  ,  -->  ERROR:  You  should  have  at  least 

one  control  arrow] 

[Control,  ,  -->  ERROR:  No  Control  Label. 

Each  Control  Arrow  should  have  a  control  Label] 
[Control,  ,  — >  RECOMMEND: 

You  would  better  reduce  the  number  of  Control  arrows 
from  1  to  5] 

[Control,  ,  -->  CORRECT:  Control  is  OK] 

[Control,  ,  -->  CORRECT:  Control  is  OK] 


Control  — > 
Trying  rule 15:: 

Trying  rulel6:: 

Trying  rulel7:: 


Trying  rulel8:: 
Proved  rulel8:: 


CORRECT:  Control  is  OK. 

[Mechanism,  , — >  ERROR:  No  Mechanism  Label. 

Each  Mechanism  Arrow  should  have  a  mechanism  Label] 
[Mechanism,  , — >  CORRECT:  No  Mechanism  Arrows,  however. 
Mechanism  is  OK] 

[Mechanism,  , — >  RECOMMEND: 

You  would  better  reduce  the  number  of  Mechanism  arrows 
from  0  to  5] 

[Mechanism,  , — >  CORRECT:  Mechanism  is  OK] 

[Mechanism,  , — >  CORRECT:  Mechanism  is  OK] 


Mechanism  — > 
Trying  rulel9:: 

Proved  rulel9:: 


CORRECT:  Mechanism  is  OK. 

[Number,  ,  — >  CORRECT:  Activity  number  is  OK. 

This  activity  must  be  the  top  most  level  box] 
[Number,  ,  — >  CORRECT:  Activity  number  is  OK. 

This  activity  must  be  the  top  most  level  box] 


Number 


— >  CORRECT: 


Activity  number  is  OK. 

This  activity  must  be  the  top  most  level  box. 
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Question:  Do  you  wish  to  see  how  this  answer 
was  arrived  at(y./n.)?  y. 

GOAL::  [Name,  ,  — >  CORRECT:  Activity  Name  is  OK] 

GOAL::  [Input,  ,  — >  CORRECT:  Input  is  OK] 

GOAL::  [Output,  ,  — >  CORRECT:  Output  is  OK] 

GOAL::  [Control,  ,  — >  CORRECT:  Control  is  OK] 

GOAL::  [Mechanism,  , — >  CORRECT:  Mechanism  is  OK] 

GOAL::  [Number,  ,  — >  CORRECT:  Activity  number  is  OK. 

This  activity  must  be  the  top  most  level  box] 
rulel9::  [Number,  ,  — >  CORRECT:  Activity  number  is  OK. 

This  activity  must  be  the  top  most  level  box]  Was  Derived  From 
[title, is, Make  Example]  AND 
[Make  Example .number. is ,0]  AND 
[0,==,0] 

SOLVED::  [0,==,0] 

TOLD::  [Make  Example .number.is ,0] 

TOLD::  [title, is, Make  Example] 

rulel8::  [Mechanism,  , — >  CORRECT:  Mechanism  is  OK]  Was  Derived  From 
[activityname.is.Make  Example] 

KNOWN::  was.told::  [activityname.is.Make  Example] 
rulel4::  [Control,  ,  — >  CORRECT:  Control  is  OK]  Was  Derived  From 

[activityname.is.Make  Example] 

KNOWN::  was.told::  [act ivityname , is .Make  Example] 
rulelO::  [Output,  ,  — >  CORRECT:  Output  is  OK]  Was  Derived  From 

[activityname.is.Make  Example] 

KNOWN::  was.told::  [activityname.is.Make  Example] 
rule6::  [Input,  ,  — >  CORRECT:  Input  is  OK]  Was  Derived  From 

[activityname.is.Make  Example] 

KNOWN::  was.told::  [activityname.is.Make  Example] 

rule2::  [Name,  ,  — >  CORRECT:  Activity  Name  is  OK]  Was  Derived  From 

[activityname.is.Make  Example]  AND 
[Make  Example , \== ,] 

SOLVED::  [Make  Example, \==,] 

TOLD::  [activityname.is.Make  Example] 

/***************** » f !  WARNING  ! ! ! ************************/ 

/*  After  this  session,  all  working  memory  elements  will  */ 

/*  be  erased  except  for  elements  being  protected  by  */ 

/*  keep  statements  in  the  knowledge  base.  */ 

/t*******************************************************/ 

Question:  Do  you  wish  to  save  the  current  working  memory 
in  a  file(y./n.)?  y. 
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Please  supply  a  filename:  ’example 


vm’ . 
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/I*************************************************************/ 


/*  */ 

/*  WELCOME  TO  IDEFO  SYNTAX  EXPERT  SYSTEMS  */ 

/*  */ 

/*  I.  Type  start.  to  begin  a  new  session.  */ 

/*  */ 

/*  II.  Answer  all  questions  using  lower  case,  ending  with  */ 
/*  a  period.  */ 

/*  */ 

/*  III.  Type  halt.  to  exit  prolog  session.  */ 

/*  */ 


/*************************************************************/ 


yes 

I  ?-  start. 

Question:  Do  you  want  verbose  operation(y./n.)?  n. 

Question:  Do  you  wish  to  check  ACTIVITY  BOX,  BOUNDARY  ARROWS 
or  to  have  HELP  MESSAGES  ? 

To  check  ACTIVITY  BOX  ->  Enter  a. 

To  check  BOUNDARY  ARROWS  ->  Enter  b. 

To  have  HELP  MESSAGE  ->  Enter  h. 

Choice  :  b. 


/***************  IDEFO 


Boundary  Input  — > 

Boundary  Output  — > 

Boundary  Control  — > 

Boundary  Mechanism  — > 


Syntax  Messages  ***************/ 
CORRECT:  Boundary  Input  is  OK. 
CORRECT : 

Boundary  Output  is  OK. 

CORRECT:  Boundary 
Control  is  OK. 

CORRECT:  Boundary 
Mechanism  is  OK. 


Question:  Do  you  wish  to  see  how  this  answer 
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was  arrived  at(y./n.)?  n. 

/***************** i i !  WARNING  !!! ************************/ 
/*  After  this  session,  all  working  memory  elements  will  */ 
/*  be  erased  except  for  elements  being  protected  by  */ 
/*  keep  statements  in  the  knowledge  base.  */ 

/it*******************************************************/ 

Question:  Do  you  wish  to  save  the  current  working  memory 
in  a  file(y./n.)?  n. 
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/*************************************************************/ 


/*  */ 

/*  WELCOME  TO  IDEFO  SYNTAX  EXPERT  SYSTEMS  */ 

/*  */ 

/*  I.  Type  start.  to  begin  a  new  session.  */ 

/*  */ 

/*  II.  Answer  all  questions  using  lower  case,  ending  with  */ 
/*  a  period.  */ 

/*  */ 

/*  III.  Type  halt.  to  exit  prolog  session.  */ 

/*  */ 


/*************************************************************/ 


yes 

I  ?-  start. 

Question:  Do  you  want  verbose  operation(y . /n. )?  y. 

Question:  Do  you  wish  to  check  ACTIVITY  BOX,  BOUNDARY  ARROWS 
or  to  have  HELP  MESSAGES  ? 

To  check  ACTIVITY  BOX  ->  Enter  a. 

To  check  BOUNDARY  ARROWS  ->  Enter  b. 

To  have  HELP  MESSAGE  ->  Enter  h. 

Choice  :  b. 


/***************  IDEFO  Syntax  Messages  ***************/ 

Trying  rule2::  [Boundary  Input,  ,  — >  !!!  THIS  IS  A  FATAL  ERROR  :  !  !] 

Trying  rulel::  [boundary s arul e , is, stalled] 

Trying  rule6::  [Boundary  Input,  ,  -->  ERROR:  No  boundary  input  label] 
Trying  rule7::  [Boundary  Input,  , — >  ERROR:  Parent  Input  has  no  label] 
Trying  rule8::  [Boundary  Input,  , — >  ERROR:  The  number  of  Input 
arrow(s)  of  Parent  Activity  box  is  greater  than  that  of 
Boundary  Input  arrow (s)  —  Must  have  the  same  number] 

Trying  rule9::  [Boundary  Input,  ,  — >  ERROR:  The  number  of  Input 

arrow(s)  of  Parent  Activity  box  is  less  than  that  of 
Boundary  Input  arrow(s)  —  Must  have  the  same  number] 

Trying  rulelO::  [Boundary  Input,  ,  — >  RECOMMEND: 

You  would  better  reduce  the  number  of  arrows  to  six 
below] 

Trying  rulell::  [Boundary  Input,  ,  -->  CORRECT:  Boundary  Input  is  OK] 

Trying  rule!3::  [Boundary  Input,  ,  — >  CORRECT:  Boundary  Input  is  OK] 
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Trying  rulel2::  [case.of .boundary.in, is  ,1] 

Trying  rulel4::  [Boundary  Input,  ,  — >  CORRECT:  Boundary  Input  is  OK] 

Trying  rulel2::  [case.of _boundary_in , is ,2] 

Proved  rulel2::  [case.of .boundary.in, is ,2] 

Proved  rulel4::  [Boundary  Input,  ,  -->  CORRECT:  Boundary  Input  is  OK] 

Boundary  Input  — >  CORRECT:  Boundary  Input  is  OK. 

Trying  rule3::  [Boundary  Output,  ,  — > 

There  is  nothing  about  Parent  activity] 

Trying  rulel::  [boundarysarule, is, stalled] 

Trying  rulel9::  [Boundary  Output,  ,-->  ERROR:  No  boundary  output  label] 
Trying  rule20::  [Boundary  Output,  ,  -->  ERROR: 

Parent  Output  has  no  label] 

Trying  rule21::  [Boundary  Output,  ,-->  ERROR:  No  boundary  output  arrow. 

Should  have  at  least  one  boundary  output  arrow] 
Trying  rule22::  [Boundary  Output,  ,  — >  ERROR:  No  parent  output  arrow. 

Should  have  at  least  one  parent  output  arrow] 

Trying  rule23::  [Boundary  Output,  ,  -->  ERROR:  The  number  of  Output 

arrow(s)  of  Parent  Activity  box  is  greater  than  that  of 
Boundary  Output  arrow(s)  --  Must  have  the  same  number] 

Trying  rule24::  [Boundary  Output,  ,  — >  ERROR:  The  number  of  Output 

arrow(s)  of  Parent  Activity  box  is  less  than  that  of 
Boundary  Output  arrov(s)  —  Must  have  the  same  number] 

Trying  rule25::  [Boundary  Output,  ,  — >  RECOMMEND: 

You  would  better  reduce  the  number  of  arrows  to  six 

[Boundary  Output,  ,  — >  CORRECT: 

Boundary  Output  is  OK] 

[case.of .boundary.out , is , 1] 

[Boundary  Output,  ,  — >  CORRECT: 

Boundary  Output  is  OK] 

[case.of .boundary.out , is , 2] 

[case.of .boundary.out , is , 2] 

[Boundary  Output,  ,  — >  CORRECT: 

Boundary  Output  is  OK] 

— >  CORRECT: 

Boundary  Output  is  OK. 

Trying  rule4::  [Boundary  Control,  ,  — > 

Maybe  you  have  tried  to  check  syntax  with 

a  file  without  PARENT  ACTIVITY  BOX  information] 

Trying  rulel::  [boundarysarule, is, stalled] 

Trying  rule33::  [Boundary  Control,  , — >  ERROR:  No  boundary  control  label] 
Trying  rule34::  [Boundary  Control,  , — >  ERROR:  Parent  Control  has  no  label] 
Trying  rule35::  [Boundary  Control,  ,  — >  ERROR:  No  boundary  control  arrow. 


below] 
Trying  rule27:: 

Trying  rule26:: 
Trying  rule28:: 

Trying  rule26: : 
Proved  rule26:: 
Proved  rule28 : : 


Boundary  Output 
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Should  have  at  least  one  boundary  control  arrow] 
Trying  rule36::  [Boundary  Control,  ,  -->  ERROR:  No  parent  control  arrow. 

Should  have  at  least  one  parent  control  arrow] 
Trying  rule37::  [Boundary  Control,  ,  — >  RECOMMEND: 

You  would  better  reduce  the  number  of  arrows  to  six 
below] 

Trying  rule39::  [Boundary  Control,  ,  — >  CORRECT:  Boundary 

Control  is  OK] 

Trying  rule38::  [case.of .boundary.con , is , 1] 

Trying  rule40::  [Boundary  Control,  ,  -->  CORRECT:  Boundary 

Control  is  OK] 

Trying  rule38::  [case.of .boundary _con, is ,2] 

Proved  rule38::  [case.of .boundary.con, is, 2] 

Proved  rule40::  [Boundary  Control,  ,  — >  CORRECT:  Boundary 

Control  is  OK] 

Boundary  Control  — >  CORRECT:  Boundary  Control  is  OK. 

Trying  ruleS::  [Boundary  Mechanism,  , — >  PLEASE  START  AGAIN  !!!] 

Trying  rulel::  [boundarysarule , is .stalled] 

Trying  rule45::  [Boundary  Mechanism,  ,-->  ERROR: 

No  boundary  mechanism  label] 

Trying  rule46::  [Boundary  Mechanism,  ERROR: 

Parent  Mechanism  has  no  label] 

Trying  rule47::  [Boundary  Mechanism,  , — >  ERROR:  The  number  of 

Mechanism  arrow(s)  of  Parent  Activity  box  is  greater  than  that 
of  Boundary  Mechanism  arrow(s)  —  Must  have  the  same 
number] 

Trying  rule48::  [Boundary  Mechanism,  ,-->  ERROR:  The  number  of 
Mechanism  arrow(s)  of  Parent  Activity  box  is  less  than 
that  of  Boundary  Mechanism  arrow(s)  —  Must  have  the  same 
number] 

Trying  rule49::  [Boundary  Mechanism,  ,-->  RECOMMEND: 

You  would  better  reduce  the  number  of  arrows  to  six 
below] 

Trying  rule50::  [Boundary  Mechanism,  ,-->  CORRECT:  Boundary 

Mechanism  is  OK] 

Trying  rule52::  [Boundary  Mechanism,  ,-->  CORRECT:  Boundary 

Mechanism  is  OK] 

Trying  rule51::  [case.of .boundary .rnech , is , 1] 

Proved  ruleSl::  [case.of .boundary.mech, is , 1] 

Proved  rule52::  [Boundary  Mechanism,  ,-->  CORRECT:  Boundary 

Mechanism  is  OK] 

Boundary  Mechanism  — >  CORRECT:  Boundary 

Mechanism  is  OK. 
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Question:  Do  you  wish  to  see  how  this  answer 
was  arrived  at(y./n.)?  y. 

GOAL::  [Boundary  Input,  ,  -->  CORRECT:  Boundary  Input  is  OK] 

GOAL::  [Boundary  Output,  ,  -->  CORRECT: 

Boundary  Output  is  OK] 

GOAL::  [Boundary  Control,  ,  -->  CORRECT:  Boundary 

Control  is  OK] 

GOAL::  [Boundary  Mechanism,  ,-->  CORRECT:  Boundary 

Mechanism  is  OK] 

rule52::  [Boundary  Mechanism,  ,-->  CORRECT:  Boundary 

Mechanism  is  OK]  Was  Derived  From 
[case_of _ boundary _mech, is, 1]  AND 
[child.title.is .Make  Example]  AND 
[Make  Example .mechanism, is .Mechanisml]  AND 
[boundary _mechanisml , is .Mechanisml] 

TOLD : :  [boundary .mechanisml , is .Mechanisml] 

TOLD::  [Make  Example ,mechanism_is .Mechanisml] 

KNOWN::  was.told::  [child.title , is .Make  Example] 
rule51::  [case.of .boundary .rnech, is , 1]  Was  Derived  From 
[boundary .mechanism, has.number , 1]  AND 
[child_title,is,Make  Example]  AND 
[Make  Example ,has_mechanism_number , 1] 

TOLD::  [Make  Example, has.mechanism.number , 1] 

KNOWN::  was.told: :  [child.title.is .Make  Example] 

TOLD: :  [boundary .mechanism, has.number , 1] 

rule40::  [Boundary  Control,  ,  -->  CORRECT:  Boundary 

Control  is  OK]  Was  Derived  From 
[case.of .boundary.con , is ,2]  AND 
[boundary_controll,is,conl]  AND 
[boundary_control2,is,con2]  AND 
[child.title.is, Make  Example]  AND 
[Make  Example, control.is, coni]  AND 
[Make  Example, control.is ,con2] 

TOLD::  [Make  Example, control.is, con2] 

TOLD::  [Make  Example, control.is , coni] 

KNOWN::  was.told::  [child.title.is .Make  Example] 

TOLD : :  [boundary_control2 , is , con2] 

TOLD::  [boundary.controll ,is ,conl] 

rule38::  [case.of .boundary. con, is, 2]  Was  Derived  From 
[boundary.control .has.number ,2]  AND 
[child.title.is, Make  Example]  AND 
[Make  Example, has.control.number ,2] 
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TOLD: : 
KNOWN: : 
TOLD: : 
rule 28 : 


TOLD:: 
TOLD: : 
KNOWN: : 
TOLD:: 
TOLD: : 
rule26: 


TOLD: : 
KNOWN: : 
TOLD : : 
rule 14: 
Was 


TOLD: : 
TOLD: : 
KNOWN: : 
TOLD: : 
TOLD: : 
rulel2: 


TOLD 

TOLD 

TOLD 


[Make  Example, has_control_number, 2] 
was.told::  [child.title.is, Make  Example] 
[boundary.control ,has_number ,2] 

[Boundary  Output,  ,  -->  CORRECT: 

Boundary  Output  is  OK]  Was  Derived  From 
[case.of .boundary.out, is, 2]  AND 
[boundary.outputl ,is ,outl]  AND 
[boundary _output2 , is ,out2]  AND 
[child_title,is,Make  Example]  AND 
[Make  Example, out put _ is, out 1]  AND 
[Make  Example, output_is ,out2] 

[Make  Example, output. is ,out2] 

[Make  Example ,output_is ,outl] 
was.told::  [child_title,is,Make  Example] 
[boundary_output2 , is , out2] 

[boundary .output 1 , is ,outl] 

[case.of .boundary .out , is ,2]  Was  Derived  From 
[boundary_output,has_number,2]  AND 
[child_title,is .Make  Example]  AND 
[Make  Example, has.output.number, 2] 

[Make  Example, has.output.number, 2] 
was.told::  [child.title.is .Make  Example] 

[boundary .output .has .number ,2] 

[Boundary  Input,  ,  -->  CORRECT:  Boundary  Input  is  OK] 

Derived  From 

[case.of .boundary. in, is, 2]  AND 
[boundary. input 1, is, in2]  AND 
[boundary _ input2, is , Ini]  AND 
[child.title.is, Make  Example]  AND 
[Make  Example, input.is ,in2]  AND 
[Make  Example , input.is , Ini] 

[Make  Example, input.is, Ini] 

[Make  Example , input.is , in2] 
was.told::  [child.title.is .Make  Example] 

[boundary. input2 , is , Ini] 

[boundary. input 1 , is , in2] 

[case.of .boundary.in, is, 2]  Was  Derived  From 
[boundary. input, has.number, 2]  AND 
[child.title.is .Make  Example]  AND 
[Make  Example, has.input.number ,2] 

[Make  Example .has.input.number ,2] 

[child.title.is, Make  Example] 

[boundary .input, has.number, 2] 
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/*****************!!!  WARNING  !!•************************/ 
/*  After  this  session,  all  working  memory  elements  will  */ 
/*  be  erased  except  for  elements  being  protected  by  */ 
/*  keep  statements  in  the  knowledge  base.  */ 
/****************************** ***************** *********/ 

Question:  Do  you  wish  to  save  the  current  working  memory 
in  a  file(y./n.)?  n. 
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/*************************************************************/ 
/*  */ 

/*  WELCOME  TO  IDEFO  SYNTAX  EXPERT  SYSTEMS  */ 

/*  */ 

/*  I.  Type  start.  to  begin  a  new  session.  */ 

/*  */ 

/*  II.  Answer  all  questions  using  lower  case,  ending  with  */ 
/*  a  period.  */ 

/*  */ 

/*  III.  Type  halt.  to  exit  prolog  session.  */ 

/*  */ 

/*************************************************************/ 


yes 

I  ?-  halt. 
ares> 
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Appendix  E.  Programmer’s  Guide 


Programmer’s  Guide  introduces  several  topics  of  interest  to  ISES  programmers 
and  developers. 
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Introduction 

The  focus  of  this  thesis  effort  was  to  design  and  implement  an  application  of 
expert  system  formulation  for  checking  IDEFo  syntax  of  IDEFo  diagrams  as  derived 
from  SAtool.  The  work  in  this  thesis  is  divided  into  two  major  ctegories:  IDEF0 
Diagram  Translator  and  IDEFo  Syntax  Expert  System.  The  IDEFo  Diagram  Trans¬ 
lator  translates  the  IDEFo  diagrams  into  a  set  of  predicate  forms  and  the  predicate 
forms  file  is  used  as  the  data  base  of  the  IDEFo  Syntax  Expert  System.  The  IDEFo 
Syntax  Expert  System  checks  the  IDEFo  syntax  of  IDEFo  diagrams.  The  objective 
of  this  appendix  is  to  specify  the  procedure  for  generating  the  executable  files  and 
to  outline  some  basic  concepts  of  the  translator  and  expert  system. 

Software  Documentation 

The  existing  source  code  is  fully  documented  in  AFIT  System  Development 
Documentation  Guidelines  and  Standards  (8).  The  following  list  shows  the  file 
header  of  the  source  codes. 

•  DATE:  Date  of  current  version  number. 

•  VERSION:  Current  version  number. 

•  TITLE:  Title  for  this  file. 

•  FILENAME:  File  name  for  the  module. 

•  DESCRIPTION:  Description  of  the  module’s  function. 

•  AUTHOR:  Name  of  one  who  responsible  for  this  file. 

•  PROJECT:  Name  of  the  software  project  of  which  this  file  is  a  part. 

•  OPERATING  SYSTEM:  Name  and  version  number  of  operating  system  under 
which  this  file  was  written. 

•  LANGUAGE:  Name  of  language  used  for  source  code. 

•  FILE  PROCESSING:  How  the  file  is  used. 
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•  CONTENTS:  Modules  contained  in  the  file. 

•  HISTORY:  List  of  major  changes  to  the  file. 

The  following  list  presents  the  subroutine  header  of  the  source  codes. 

•  DATE:  Date  of  the  module. 

•  VERSION:  Current  version  number. 

•  NAME:  Module  name. 

•  MODULE  NUMBER:  Module  number  of  current  program. 

•  DESCRIPTION:  Text  description  of  the  module’s  function. 

•  ALGORITHM:  Algorithm  used. 

•  PASSED  VARIABLES:  Variables  passed  to  the  module. 

•  RETURNS:  Value  returned  b>  the  module. 

•  GLOBAL  VARIABLES  USED:  Variables  read  by  the  module. 

•  GLOBAL  VARIABLES  CHANGED:  Variables  changed  by  the  module. 

•  FILES  READ:  Files  read  by  the  module. 

•  FILES  WRITTEN:  Files  written  by  the  module. 

•  HARDWARE  INPUT:  I/O  ports  read. 

•  HARDWARE  OUTPUT:  I/O  ports  read. 

•  MODULES  CALLED:  Other  procedures  called. 

•  CALLING  MODULES:  What  modules  call. 

•  AUTHOR:  One  who  wrote  this  module. 

•  HISTORY:  List  of  major  changes  to  the  module. 
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OBJECTS  =  main.o  dataddict.o  messages.o  boxfunctions.o 
headerfunctions.o  editboxfunc.o 
miscfunctions.o  ddsearchfuncs.o 
endfuncs.o  find.o  morelinefuncs.o 
linelabel.o  moreddfuncs.o  ddsearchfuncs.o 
savefuncs.o 

fptfuncs.o  sqglefuncs.o  fnotefuncs.o 
moresave.o  screendump.o  readfuncs.o 
session .o  syntaxfuncs.o 

HEADERS  =  globals.h 

ALL  =  sad 

CFLAGS  =  -O 

LIBS  =  -lsuntool  -lsunwindow  -lpixrect  -lm 
sad  :  $(OBJECTS) 

cc  $(CFLAGS)  $(OBJECTS)  S(LIBS)  -o  SAtool 


Figure  E.l.  Contents  of  Makefile 

Make  File 

The  file  of  the  IDEFo  Diagram  Translator  is  included  in  the  files  of  the  SAtool 
because  the  IDEF0  Diagram  Translator  was  coded  as  a  part  of  the  SAtool  under 
the  SunOS™.  The  file  name  of  source  code  for  the  IDEF0  Diagram  Translator  is 
syntaxfuncs.c.  The  executable  file  was  produced  by  using  the  UNIX  make  utility. 
Figure  E.l  shows  the  contents  of  the  Makefile  file.  The  system  command  make  causes 
to  be  compiled  and  linked  all  together  and  generated  the  executable  file,  SAtool. 


Files  produced  by  IDT 

*.pro  This  file  contains  a  set  of  predicate  data  forms  into  which  the  IDEF0 
Diagram  Translator  translates  the  IDEF0  diagram.  The  symbol  *  is  a  file  name 
which  the  user  specifies.  The  extension  of  the  file  is  added  automatically.  This  file  is 
used  to  check  the  IDEFo  syntax  of  boundary  arrows  in  any  IDEF0  diagram.  Figure 
E.3  shows  an  example  of  the  predicate  data  file  translated  from  the  above  IDEFo 
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diagram  shown  in  Figure  E.2.  Also,  Figure  E.4  shows  an  example  of  the  predicate 
data  file  from  the  below  IDEFo  diagram  shown  in  Digure  E.2. 

CHECKBOX. PRO  This  file  is  a  temporary  file  which  is  created  and  overwrited 
automatically.  Also  this  file  is  used  for  checking  the  IDEFo  syntax  of  an  activity  box 
which  user  specifies  in  any  IDEFo  diagram.  Figure  E.5  represents  the  predicate  data 
file  of  the  activity  box,  boxl,  which  is  clicked  by  the  user  in  Figure  E.2. 

CHECKBOUNDARY. PRO  This  file  contains  the  predicate  data  forms  of  the 
boundary  arrows  and  its  parent  activity  box  and  is  a  temporary  file  which  is  created 
and  overwrited  automatically.  Also  this  file  becomes  the  data  base  (working  memory) 
of  the  IDEFo  Syntax  Expert  System.  Figure  E.6  shows  the  predicate  data  file  of 
boundary  arrows  in  Figure  E.2. 
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Figure  E.2.  Example  of  IDEFo  Diagram 
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conf irmed( [title,  is,  ’Make  Example’]), 
conf irmed( [node ,  is,  ’AO’]). 

conf irmed( [activityname ,  is,  ’Make  Example’]). 

conf irmed( [’Make  Example ’ , number. is ,0] ) . 

conf irmed( [’Make  Example ’ , input.is , ’ Ini ’] ) . 

conf irmed( [’Make  Example’ , input.is , ’ in2’] ) . 

conf irmed( [’Make  Example’,  has_input_number ,  2]). 

conf irmed( [’Make  Example’ .output. is, ’outl’]) . 

conf irmed( [’Make  Example’ .output.is, ’out2’]) . 

conf irmed( [’Make  Example’ ,  has.output.number ,  2]). 

conf irmed( [’Make  Example’ .control.is, ’coni’] ) . 

conf irmed( [’Make  Example’ .control.is, ’con2’]) . 

conf irmed( [’Make  Example’,  has.control.number ,  2]). 

conf irmed( [’Make  Example’ .mechanism. is , ’Mechanisml ’] ) . 

conf irmed( [’Make  Example’ ,  has.mechanism.number ,  1]). 


Figure  E.3.  Predicate  Data  File  Produced  by  Save  (-pro)  (parent) 
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conf irmed( [title ,  is,  ’Hake  Example’]). 

confirmed( [node,  is,  ’ A1 ’ ] ) . 

conf irmed( [activityname,  is,  ’boxl’]). 

conf irmed( [’boxl ’ ,number_is , 1]  ) . 

conf irmed ( [’boxl ’ , input. is , ’ in2’] ) . 

conf irmed( [’boxl ’ , input .is , ’ Ini '] ) . 

conf irned( [’boxl ’ ,  has.input.number,  2]). 

conf irmed ( [’boxl ’ .output. is , 1 out2’] ) . 

conf irmed( [’boxl ’  ,  has.output.number,  1]). 

conf irmed ( [ ’boxl ’ .control. is , ’ coni’]  ) . 

conf irmed( [’boxl ’ ,  has.control.number,  1]). 

conf irmed( [’boxl ’ .mechanism. is .null]  ) . 

conf irmed( [activityname,  is,  ’box2’]). 

conf irmed( [’box2’ .number.is ,2] ) . 

conf irmed( [’box2 ’ , input. is , ’out2 ’] ) . 

conf irmed( [’box2* .input.is, ’in3’]) . 

conf irmed( [’box2’  ,  has.input.number,  2]). 

conf irmed ( [’box2’ .output. is , ’ in2’] ) . 

conf irmed( [’box2’ .output.is, ’outl’]) . 

conf irmed ( [ ’ box2 ’ .output.is, ’out4’]) . 

conf irmed( ['box2’ ,  has.output.number,  3]). 

confirmed( [’box2’ .control.is, ’con2’]) . 

conf irmed ( [’box2’ .control.is , ’con3’] ) . 

conf irmed( [’box2’ ,  has.control.number ,  2]). 

conf irmed([’box2’ .mechanism.is .null]  ) . 

conf irmed( [activityname,  is,  ’box3’]). 

conf irmed ( [’box3’ .number.is ,3]  ) . 

confirmed([’box3' .input.is, ’in4’]) . 

conf  irmed(  [’box3’ ,  has.input.number,  1]). 

conf irmed ( [’box3’ .output.is , ’out2’] ) . 

conf irmed([’box3’ .output.is , ’con3’] ) . 

conf irmed( [’box3’ ,  has.output.number,  2]). 

conf irmed ( [’box3’ , control.is , ’ out4 ’] ) . 

confirmed([’box3’ ,  has.control.number,  1]). 

conf irmed( [’box3’ .mechanism.is , ’Mechanisml ’] ) . 

conf irmed( [’box3’ ,  has.mechanism.number ,  1]). 


Figure  E.4.  Predicate  Data  File  Produced  by  Save  (.pro)  (child) 
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conf irmed( [title,  is,  ’Make  Example’]), 
confirmed ([node,  is,  ’Al’]). 
conf irmed( [activityname,  is,  ’boxl’]). 
conf irmed( [’boxl’ .number. is  ,  1] )  . 
conf irmed( [’boxl ’ .input.is, ’in2’]) . 
conf irmed( [’boxl ’ .input.is, ’Ini’]) . 
conf irmed( [’boxl ’ ,  has.input.number ,  2]). 
conf irmed( [’boxl ’ .output .is , ’out2’] ) . 
conf irmed( [’boxl ’ ,  has.output .number ,  1]). 
conf irmed( [’boxl ’ .control.is, ’coni’]) . 
conf irmed( [’boxl ’ ,  has.control.number ,  1]). 
conf irmed( [’boxl ’ .mechanism.is .null] ) . 


Figure  E.5.  Predicate  Data  File  Produced  by  Activity 
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confirmed(  [title,  is,  ’Make  Example’]), 
conf irmed(  [node ,  is,  ’AO’]). 

conf irmed(  [activitynaroe ,  is,  ’Make  Example’]). 

conf irmed( [’Make  Example  * .number. is ,0] )  . 

conf irmed(  [’Make  Example’ , input _is , ’ Ini  ’] ) . 

conf irmed( [’Make  Example’ .input.is , ’ in2’] ) . 

conf irmed( [’Make  Example’,  has.input .number ,  2]). 

conf irmed(  ['Make  Example' .output.is , 'outl '] ) . 

conf irmed(  [’Make  Example’ .output.is , ’out2’] ) . 

conf irmed(  [’Make  Example’,  has.output.number ,  2]). 

conf irmed( [’Make  Example’ .control.is, ’coni’] ) . 

conf irmed( [’Make  Example’ .control.is , 'con2'] ) . 

conf irmed( [’Make  Example’,  has.control.number ,  2]). 

conf irmed( [’Make  Example’ .mechanism. is , 'Mechanisml ’] ) . 

conf irmed(  [’Make  Example’ ,  has.mechanism.number ,  1]). 

conf irmed( [child.title,  is,  ’Make  Example’]). 

conf irmed( [boundary.controll ,  is,  ’coni’]). 

conf irmed( [boundary.outputl ,  is,  ’outl’]). 

conf irmed( [boundary _output2,  is,  ’out2’]). 

conf irmed( [boundary. input 1 ,  is,  ’in2’]). 

conf irmod( [boundary _control2,  is,  ’con2']). 

conf irmed( [boundary. input 2,  is,  ’Ini’]). 

conf irmed( [boundary.mechanisml ,  is,  ’Mechanisml’]). 

conf irmed( [boundary .input ,  has.number,  2]). 

conf irmed( [boundary .output,  has.number,  2]). 

conf irmed( [boundary. control ,  has.number,  2]). 

conf irmed( [boundary.mechanism,  has.number,  1]). 


Figure  E.6.  Predicate  Data  File  Produced  by  Boundary 
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Appendix  F.  Source  Code 


The  purpose  of  this  appendix  represents  the  source  code  which  was  imple¬ 
mented  during  this  thesis  investigation.  This  appendix  contains  two  main  source 
codes:  one  for  IDEFo  Diagram  Translator,  the  other  for  IDEFo  Syntax  Expert  Sys¬ 
tem. 
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IDEFq  Diagram  Translator 

The  purpose  of  this  section  is  to  provide  the  source  code  documentation  of 
the  IDEFo  Diagram  Translator.  The  documentation  conformed  to  the  software  en¬ 
gineering  standards  in  AFIT’s  System  Development  Documentation  Guidelines  and 
Standards  draft  #4  (8). 
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/************************************************************************ 


*  * 

*  DATE:  3  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  TITLE:  IDEFO  Diagram  Translator  * 

*  FILENAME:  syntaxfuncs .c  * 

*  DESCRIPTION:  * 

*  This  file  provides  a  means  of  translating  the  IDEFO  diagram  * 

*  into  a  set  of  predicate  forms  and  generating  the  predicates  * 

*  files  as  the  data  base  of  IDEFO  Syntax  Expert  System.  * 

*  PROJECT:  AI  * 

*  OPERATING  SYSTEM:  UNIX  4.3  * 

*  LANGUAGE:  C  * 

*  FILE  PROCESSING:  Must  compile  with  SAtool.  * 

*  CONTENTS:  check_input_abox() ,  single_headed_input ()  ,  * 

*  double_headed_ input () ,  double_headed_input_with_slash() ,  * 

*  check.output.aboxO »  single_headed_output() ,  * 

*  double_headed_output.with_control() ,  * 

*  double.headed.output.with.inputO ,  double.headed.outputO* 

*  check.control.aboxO ,  single_headed_control() ,  * 

*  double_headed_control_vith_slash() ,  * 

*  double.headed.controlO  ,  check_mechanism_abox() ,  * 

*  single_headed_mechanism() ,search_labels_touched_abox() ,  * 

*  get_labels_for_abox() ,  save_arrow_info_of_abox() ,  * 

*  create_temp_box_info() ,  f ind_clicked_box() ,  * 

*  check.button.for.activityQ ,  check_activity() ,  * 

*  create_temp_boundary_info() ,  check.parent.box.f ile() ,  * 

*  check_button_f or. boundary () ,  check.boundaryO ,  * 

*  save.null.boundaryO ,  search.NLR.boundary.line.infoO ,  * 

*  search_boundary_info() ,  save.boundary.line.infoO ,  * 

*  save_header_info() ,  traverse.boxes ()  ,  store.predicatesQ ,* 

*  overwrite_predicates() ,  get.f ilename.for.predicatesO  * 

*  save.predicatesO  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  10/Jan/90  :  Modify  the  print  out  format  * 

*  02/Feb/90  :  Add  save.header.inf o()  * 

*  04/Feb/90  :  Add  save.boundary.inf o()  * 


***********************************************************************/ 

♦include  <stdio.h> 

#include  <suntool/sunview .h> 

♦include  <suntool/canvas .h> 

♦include  <suntool/panel .h> 
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#include  <suntool/textsv.h> 

#include  <sys/param.h> 

#include  "globals.h" 

/**********************  globals  to  this  file  ***************************/ 

int  number.of .boundary .input ,  number.of .boundary .output ; 

int  number.of .boundary .control ,  number.of .boundary .mechanism; 

char  last.f ile.name [FILE.NAME.LENGTH  +5]  = 

struct  text.line.struct  *Line_labels ; 
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/>M********** ************************************************ ************ 


*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  check.input.aboxQ  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  generating  a  linked  * 

*  list,  Line.labels,  with  all  information  labels  of  input  * 

*  arrows  attatched  on  an  activity  box.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  Line.labels  * 

*  GLOVAL  VARIABLES  CHANGED:  Line.labels  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT: None  * 

*  MODULES  CALLED:  signle_headed_ input () ,  double_headed_ input ()  * 

*  double.headed.input.with.slashO  * 

*  CALLING  MODULES:  search.labels.touched.aboxQ  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 

I**##*****#*#***********************************************************/ 

void 

check, input, abox (tem.line) 
struct  line.struct  *tem_line; 

{ 

extern  struct  text.line.struct  *Line_labels ; 

extern  add_to_inputs_tree() ; 

char  buf [DESCRIPTION.LINE.LENGTH+l] ; 

single.headed.input (tem.line) ; 
double.headed, input (tem.line) ; 
double.headed.input.with. slash( tem.line) ; 
return; 

> 
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/**********#*******#*******************************+*****★************* 


*  DATE:  25  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  single_headed_ input ()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  This  module  provides  a  means  of  hooking  the  line  * 

*  labels  of  input  arrows  with  single  head  to  a  linked  * 

*  list,  Line.label.  * 

*  ALGROTHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  box .line .Line.labels  * 

*  GLOBAL  VARIABLES  CHANGED:  Line.labels  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  get_closest_label()  ,  get_branchnode() ,  * 

*  f ind_TO_ALL_branchnode() ,  f ind.branchnodeQ ,  * 

*  add_to_inputs_tree()  * 

*  CALLING  MODULES:  check.input.aboxO  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 


*********************************************************************/ 
single.headed. input (tem.line) 
struct  line. struct  *tem_line; 

{ 

extern  get.closest.labelO ,get_branchnode() ,f ind_TO_ALL_branchnode() ; 

extern  f ind.branchnodeO ,add_to_inputs_tree() ; 

extern  struct  box.struct  *box; 

extern  struct  line.struct  *line; 

struct  line.struct  *original_line ; 

char  buf [DESCRIPTION.LINE.LENGTH  +1]; 

int  original. line.type; 

if(  /*  check  if  tem.line  is  touched  on  the  left  side  of  */ 

/*  box  with  10  deviation.  */ 

(tem_line->end_position.x  >=  box->swcorner .x-10)  AA 
(tem_line->end_position.x  <=  box->swcorner .x)  iA 
(tem_line->end_position.y  <■  box->swcorner .y)  AA 
(tem_line->end_position.y  >=  box->swcorner .y-B0X_HT)  AA 
(  /*  check  if  tem.line  has  an  end  arrow  */ 
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(tem_line->end_activity_num  4  (ARROW.HEAD))  !=  0)  44 
((tem_line->end_activity_num  4  (DOT_B_L|DOT_T_R))  ==  0))  { 

/*  This  tem.line  is  an  input  arrow  for  temp.box  with  some  */ 

/*  toralence,  i.e.  not  require  the  line  must  be  touched  box  */ 

/*  so  as  to  be  an  input  arrow(single  headed  arrow).  */ 

original_line_type  =  get.branchnode (tem.line) ; 
original_line  =  (struct  line_struct  *) 
f ind_branchnode(original_line_type) ; 

if (get_closest_label(original_line,buf ,tem_line->struct_type) 

==  MYTRUE) 

{  /*  tem_line  has  a  line  label  */ 

Line.labels  =  (struct  text_line_struct  +) 
add_to_inputs_tree(Line_labels ,buf ) ; 
return ; 

> 

/*  No  line  label  on  tem.line  -  Check  if  tem.line  is  a  FR0M_ALL  */ 
/*  type  line.  If  so,  search  TO.ALL  and  its  label  */ 

if (original_line->start_activity_num  ==  FR0M_ALL)  { 
original.line  =  (struct  line.struct  *) 
f ind_TO_ALL_branchnode(original_line->to_from_label) ; 
original_line_type  =  get_branchnode(original_line) ; 
original_line  =  (struct  line.struct  *) 
find.branchnode(original.line.type) ; 

if (get. closest.label (original. line, buf ,line->struct .type) 

==  MYTRUE) 

{ 

Line.labels  *  (struct  text.line.struct  *) 

add_to_inputs_tree(Line_labels,buf ) ; 

return ; 

> 

> 

strcpy(buf ,"") ; 

Line.labels  *  (struct  text.line.struct  *) 
add.to.inputs.tree (Line.labels ,buf ) ; 

> 

return ; 

> 
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/********************************************************************** 


*  * 

*  DATE:  16  Feb  1990  * 

*  VERSION:  1.0  * 

*  NAME  :  double_headed_ input ()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  This  module  provides  a  linked  list(Line_labels)  which  * 

*  has  the  labels  of  the  input  arrows  touched  on  an  * 

*  activity  box  with  double  head.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  box,  line  * 

*  GLOBAL  VARIABLES  CHANGED:  Line.labels  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  get2_closest_label() ,  f ind_branchnode() ,  * 

*  f ind_TO_ALL_branchnode() ,  get.branchnodeQ ,  * 

*  add_to_inputs_tree()  * 

*  CALLING  MODULES:  check.input.aboxO  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 


*********************************************************************/ 
double_headed_ input (tem.line) 
struct  line.struct  *tem_line; 

{ 

extern  get2_closest_label() ,f ind.br anchnodeO ,f ind_TO_ALL_branchnode() ; 

extern  get.branchnodeO ,add_to_inputs_tree() ; 

extern  struct  box.struct  *box; 

extern  struct  line.struct  *line; 

struct  line.struct  *original_line; 

char  buf [DESCRIPTION.LINE.LENGTH  +1]  ; 

int  original.line.type; 

if ((tem_line->end_position.x  >=  box->swcorner .x-10)  ftft 
(tem_line->end_position.x  <=  box->swcorner .x)  ftft 
(tem_line->end_position.y  <=  box->swcorner.y)  ftft 
(tem_line->end_position .y  >=  box->swcorner .y-B0X_HT)  ftft 
(  /*  tem.line  is  an  input  arrow  with  a  double  headed  arrow  */ 

/*  in  some  extend(toralence) .  */ 

(tem_line->end_activity_num  ft  (ARROW.HEAD))  !  =  0)  ftft 
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((tem_line->end_activity_num  &  (DOT_T_R))  !=  0))  { 
original_line_type  =  get_branchnode(tem_line) ; 
original.line  =  (struct  line.struct  *) 
f ind_branchnode(original_line_type) ; 

if(/*  Exists  the  line  label  on  tem.line  */ 
get2_closest_label(original_line,buf ,tem_line->struct_type) 

==  MYTRUE)  { 

Line.labels  =  (struct  text_line_struct  *) 
add_to_inputs_tree(Line_labels ,buf ) ; 
return ; 

> 

/*  No  line  label  on  tem.line  -  Check  if  tem.line  is  a  FROM.ALL  */ 
/*  type  line.  If  so,  search  T0_ALL  and  its  label.  */ 

if (original_line->start_activity_num  ==  FROM.ALL)  { 
original.line  =  (struct  line.struct  *) 
f ind_TO_ALL_branchnode(original_line->to_from_label) ; 

original_line_type  =  get_branchnode(original_line) ; 
original.line  =  (struct  line.struct  *) 
f ind_branchnode(original_line_type) ; 

if (get2_closest_label (original.line, buf ,line->struct_type) 

==  MYTRUE)  { 

Line.labels  =  (struct  text.line.struct  *) 
add_to_inputs_tree(Line_labels ,buf ) ; 
return; 

> 

> 

strcpy(buf ,"") ; 

Line.labels  =  (struct  text.line.struct  *) 
add_to_inputs_tree(Line_labels ,buf ) ; 

> 

return ; 

> 
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/********************************************************************* 


*  * 

*  DATE:  16  Feb  1990  * 

*  VERSION:  1.0  * 

*  NAME  :  double_headed_input_with_slash()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  This  module  provides  a  means  of  adding  the  line  * 

*  labels  with  a  slash  of  input  arrows  with  double  head  * 

*  to  Line.labels  structure  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tern. line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  box  * 

*  GLOBAL  VARIABLES  CHANGED:  Line.labels  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  get3_f irst.labelO ,  add_to_inputs_tree()  * 

*  CALLING  MODULES:  check. input_abox()  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 


********************************************************************/ 
double.headed. input. with.slash(tem.line) 
struct  line.struct  *tem_line; 

{ 

extern  get3_first_label() , add_to_inputs_tree() ; 

extern  struct  box. struct  *box; 

char  buf [DESCRIPTION.LINE.LENGTH  +1] ; 

if (Ctem_line->start_position.x  <  box->swcorner .x+BOX.WIDTH+15)  kk 
(tem_line->start_position.x  >=  box->swcorner .x+BQX_WIDTH)  kk 
(tem_line->start_position.y  <=  box->swcorner .y)  kk 

((tem_line->start_activity_num  k  (ARROW.HEAD) )  !=0)  kk 

((tem_line->start_activity_num  k  (DOT.B.L))  !=  0)) 

{ 

if (get3_f irst_label(tem_iine,buf)  =*  MYTRUE)  { 

Line.labels  ■  (struct  text.line.struct  *) 
add_to_inputs_tree(Line_labels,buf ) ; 
return ; 

> 

strcpy(buf ; 

Line.labels  ■  (struct  text.line.struct  *) 
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add_to_inputs_tree(Line_labels ,buf ) ; 
return; 

> 
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/>M********************************* *************************** ****** 


*  * 

*  DATE:  17  Feb  1990  * 

*  VERSION:  1.0  * 

*  NAME:  check_output_abox()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  generating  a  linked  * 

*  list,  Line_labels,  with  all  information  labels  of  * 

*  output  arrows  attatched  on  an  activity  box.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  Line.labels  * 

*  GLOBAL  VARIABLES  CHANGED:  Line_labels  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  single_headed_output() ,  double_headed_output()  * 

*  double_headed_output_with_ input ()  * 

*  double_headed_output_with_control()  * 

*  CALLING  MODULES:  search_labels_touched_abox()  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 


*******************************************************************/ 

void 

check_output_abox(tem_line) 
struct  line.struct  *tem_line; 

{ 

extern  struct  text.line.struct  *Line_labels ; 

single_headed_output(tem_line) ; 
double_headed_output_with_control (tem_line) ; 
double_headed_output_with_input(tem_line) ; 
double_headed_output(tem_line) ; 
return; 

} 
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/*********%********************************************+************** 


* 


* 


*  DATE:  17  Feb  1990  * 

*  VERSION:  1.0  * 

*  NAME:  single_headed_output()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 


*  This  module  provides  a  means  of  adding  line  labels  of  * 


*  output  arrows  with  single  head.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  Line.labels  * 

*  GLOBAL  VARIABLES  CHANGED:  Line.labels  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  get_f irst.labelQ ,  add_to_inputs_tree()  * 

*  CALLING  MODULES:  check.output.aboxQ  * 

*  AUTHOR:  Intaek  Kim  * 


*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 

********************************************************************/ 
single_headed_output (tem.line) 

struct  line.struct  *tem_line; 

extern  get_f irst.labelQ ,add_to_inputs_tree() ; 
char  buf [DESCRIPTION.LINE.LENGTH  +1]; 


if(/*  Output  leaves  the  right  side  of  a  box  -  single  headed  arrow  */ 
(tem_line->start_position.x  <  box->swcorner .x+B0X_WIDTH+15)  && 

(tem_line->start_position.x  >=  box->swcorner .x+BOX_WIDTH)  && 

(tem_line->start_position.y  <=  box->swcorner .y)  Aft 

(tem_line->start. position. y  >=  box->swcorner .y-B0X_HT)  && 

((tem.line->start_activity_num  k  (ARROW.HEAD))  ==  0)) 

if (get_first_label(tem_line,buf )  ==  MYTRUE)  { 

Line.labels  =  (struct  text.line.struct  *) 
add_to_inputs_tree(Line_labels ,buf ) ; 
return ; 

> 

strcpy(buf ; 

Line.labels  «  (struct  text.line.struct  *) 
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add_to_inputs_tree(Line_labels ,buf ) ; 

> 

return; 
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/I********************************************************************* 


*  * 

*  DATE:  17  Feb  1990  * 

*  VERSION:  1.0  * 

*  NAME:  double.headed.output.with.controlO  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  adding  the  line  labels* 

*  of  the  output  arrows  with  double  heads  which  become  * 

*  controls  of  another  activity  box  to  a  linked  list.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  line,  Line.labels  * 

*  GLOBAL  VARIABLES  CHANGED:  Line.labels  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  get_branchnode() ,  f ind.branchnode () ,  * 

*  get3_closest.label() ,  f ind_TO_ALL_branchnode()  * 

*  add_to_inputs_tree()  * 

*  CALLING  MODULES:  check. output. abox()  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY :  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 


********************************************************************/ 
double.headed.output.with.control (tem.line) 
struct  line.struct  *tem_line; 

{ 

extern  get.br  anchnodeQ ,f ind.br anchnodeQ ,get3_closest_label() ; 
extern  f ind_TO_ALL.br anchnodeQ ; 
extern  struct  line.struct  ♦line.¬ 
struct  line.struct  *original_line; 
char  buf [DESCRIPTION.LINE.LENGTH+l] ; 
int  original. line.type; 


if(/*  Output  with  a  double  headed  control  arrow  -  need  to  */ 

/*  search  the  tem.line  for  the  closest  label  with  a  slash  */ 
/*  and  get  the  label  after  the  slash.  */ 

(tem_line->end_position.y  >  box->swcorner.y-B0X_HT-15)  kk 

(tem_line->end_position.y  <*  box->swcorner.y-BOX_HT)  kb 

(tem_line->end_position.x  <*  box->swcorner .x+BOX_WIDTH)  kk 

(tem_line->end_position.x  >=  box->swcorner .x)  kk 
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((tem_line->end_activity_num  k  (ARROW.HEAD))  !=  0)  kk 

((tem_line->end_activity_num  k  (DOT.B.L))  !=  0)) 

{ 

original. line.type  -  get.branchnode (tem.line) ; 

original.line  =  (struct  line.struct  *) 
f ind_branchnode(original_line_type) ; 

if (get3_closest .label (original.line, buf, tern. line-> struct .type) 
==  MYTRUE)  { 

Line.labels  =  (struct  text.line.struct  *) 
add_to_inputs_tree(Line_labels  ,buf ) ; 
return ; 

> 

/*  No  line  label  on  tem.line  -  Check  if  tem.line  is  a  */ 

/*  FROM.ALL  type  output.  If  so,  search  TO.ALL  and  its  label.*/ 
if (original_line->start_activity_num  *®  FROM.ALL)  { 
original.line  =  (struct  line.struct  *) 
f ind_TO_ALL_branchnode(original_line->to_from_label) ; 

original.line.type  =  get.branchnode(original.line) ; 
original.line  =  (struct  line.struct  *) 
find.branchnode (original.line.type) ; 

if(/*have  found  the  branchnode  of  the  TO.ALL  line  segment*/ 
get3_closest_label (original.line ,buf , line->struct_type) ) 

•C 

Line.labels  »  (struct  text.line.struct  *) 
add.to_inputs.tree (Line.labels ,buf ) ; 
return ; 

> 

> 

8trcpy(buf ,"") ; 

Line.labels  =  (struct  text.line.struct  *) 
add.to_inputs.tree (Line.labels ,buf ) ; 

> 

return ; 

} 
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/******************************************************************** 


*  DATE:  17  Feb  1990  * 

*  VERSION:  1.0  * 

*  NAME  :  double_headed_output_with_input()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  This  module  provides  a  means  of  adding  the  line  * 

*  labels  of  the  output  with  double  heads  and  the  slash* 

*  to  a  linked  list,  Line.labels.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  line  * 

*  GLOBAL  VARIABLES  CHANGED:  Line.labels  * 

*  FILE  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  get_branchnode() ,  f ind.branchnodeO ,  * 

*  get3_closest_label() ,  add_to_inputs_tree()  * 

*  f ind_TO_ALL_branchnode()  * 

*  CALLING  MODULES:  check_output_abox()  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 


*******************************************************************/ 
double_headed_output  _with_ input (t em_l ine ) 
struct  line.struct  *tem_line; 

{ 

extern  get_branchnode() ,f ind_branchnode() ,get3_closest_label() ; 

extern  add_to_inputs_tree() ,f ind.TO. ALL.br anchnodeC) ; 

extern  struct  line.struct  *line; 

struct  line.struct  *original_line; 

int  original_line_type; 

char  buf [DESCRIPTION.LINE.LENGTH  +1] ; 

if(/*  tem.line  is  an  output  with  a  double  headed  input  */ 

/*  arrow  on  a  box  */ 

(tem_line->end_position.x  >=  box->swcorner .x  -15)  Aft 

(tem_line->end_position.x  <*  box->swcomer.x)  ftft 

(tem_line->end_position.y  <*  box->swcorner .y)  Aft 

(tem_line->end.position.y  >*  box->swcorner.y  -B0X_HT)AA 

((tem_line->end_activity_num  k  (ARROW.HEAD))  !=  0)  Aft 
((tem_line->end_activity_num  A  (DOT.T.R))  !=  0)) 
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original.line.type  =  get.branchnode(tem.line) ; 
original.line  =  (struct  line.struct  *) 

find.branchnode (original.line.type) ; 
if(/*  Exists  label  on  the  original  line  */ 
get3_closest_label(original_line ,buf ,tem_line->struct_type) 
==  MYTRUE)  { 

Line.labels  =  (struct  text_line_struct  *) 
add.to.inputs.tree (Line.labels , buf ) ; 
return ; 

} 

if(/*  No  line  label  on  tem.line  -  Check  if  */ 

/*  tem.line  is  a  type  of  FROM.ALL  */ 

/*  line.  If  so,  Search  TO.ALL  and  its  label.  */ 
original_line->start_activity_num  ==  FROM.ALL) 

{ 

original.line  =  (struct  line.struct  *) 
f ind_TO_ALL_branchnode(original_line->to_from_label) ; 

original.line.type  =  get.branchnode (original.line) ; 
original.line  *  (struct  line.struct  *) 

f ind.branchnode (original.line.type) ; 
if(/*  Find  the  branchnode  of  the  TO.ALL  line  segment  */ 
get3_closest_label (original.line, buf ,line->struct_type) 
*=  MYTRUE) 

Line.labels  =  (struct  text.line.struct  *) 
add_to_inputs_tree(Line_labels ,buf ) ; 
return; 

> 

> 

strcpy  (buf  ,'■"); 

Line.labels  =  (struct  text.line. struct  *) 
add_to_inputs_tree(Line_labels ,buf ) ; 

> 

return ; 

> 
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/********************************************************************* 


*  * 

*  DATE:  17  Feb  1990  * 

*  VERSION:  1.0  * 

*  NAME:  double.headed.outputQ  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  This  module  provides  a  means  of  adding  the  line  * 

*  labels  of  the  output  with  double  heads  to  a  linked  * 

*  list,  Line.labels.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  Line.labels  * 

*  1L0BAL  VARIABLES  CHANGED:  Line.labels  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HAREWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  get2_f irst_label() ,  add_to_inputs_tree()  * 

*  CALLING  MODULES:  check_output_abox()  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 


********************************************************************/ 
double_headed_output (tem.line) 
struct  line.struct  *tem_line; 

•c 

extern  get2_f  irst.labelO ,add_to_inputs_tree() ; 

char  buf [DESCRIPTION.LINE.LENGTH  +1]  ; 

if(/*  Output  line  leaves  the  right  side  of  a  box  and  there  is  */ 

/*  a  double  headed  arrow.  */ 

(tem_line->start_position ,x  <=  box->swcorner .x  +  BOX.WIDTH  +  10)  Aft 

(tem_line->start_position.x  >=  box->swcorner .x  +  BOX.WIDTH)  &ft 

(tem_line->8tart_position.y  <=  box->swcorner .y)  ftft 

(tem_line->start_position.y  >=  box->swcorner .y  -  BOX.HT)  &ft 

((tem_line->start_activity_num  ft  (ARROW.HEAD))  !=  0)  ft& 

((tem_line->start_activity_num  ft  (D0T_B.LlD0T.T_R))  !=  0)) 

{ 

if (get2_f irst.label(tem_line ,buf )  ==  MYTRUE)  •[ 

Line.labels  =  (struct  text.line.struct  *) 

add_to_inputs_tree(Line_labels ,buf ) ; 

return; 

> 
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strcpy(buf ; 

Line.labels  =  (struct  text.line.struct  *) 

add_to_inputs_troe(Line_labels ,buf ) ; 

> 

return; 

> 
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/******************************************************************** 
*  * 

*  DATE:  19  Feb  1990  * 

*  VERSION:  1.0  * 

*  NAME:  check_control_abox()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  This  module  provides  a  means  of  generating  a  linked  * 

*  list(Line_labels)  which  has  the  information  of  labels* 

*  of  the  control  arrows  attatched  on  an  activity  box.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tern. line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  None  * 

*  GLOBAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  single_headed_control() ,  double_headed_control()  * 

*  double_headed_control_with_slash()  * 

*  CALLING  MODULES:  search_labels_touched_abox()  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 

*******************************************************************/ 
void 

check_control_abox(tem_line) 
struct  line.struct  *tem_line; 

{ 

extern  struct  text.line.struct  *Line_labels ; 

single_headed_control(tem_line) ; 
double_headed_control (tem.line) ; 
double_headed_control_with_slash(tem_line) ; 
return ; 

> 
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/********************************************************************* 


*  * 

*  DATE:  19  Feb  1990  * 

*  VERSION:  1.0  * 

*  NAME:  single.headed.controlO  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  This  module  provides  a  means  of  adding  the  line  * 

*  labels  of  the  control  arrows  with  a  single  head  to  * 

*  the  linked  list,  Line.labels.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  line,  Line.labels  * 

*  GLOBAL  VARIABLES  CHANGED:  Line.labels  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  get.closest.labelQ ,  add_to_inputs_tree()  * 

*  get.br an chnodeQ  ,  f  ind.br anchnodeO  ,  * 

*  f ind_TO_ALL_branchnode()  * 

*  CALLING  MODULES:  check.control.aboxO  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 


♦  ♦l****^*#******************#******#*******  *********************** 

single_headed_control(tem_line) 
struct  line. struct  *tem_line; 

{ 

extern  get.closest.labelO ,add_to_inputs_tree() , get.br anchnodeO ; 

extern  f ind.branchnodeO ,f ind.TO.ALL.branchnodeC) ; 

extern  struct  line.struct  *line; 

struct  line.struct  *original_line; 

int  original.line.type; 

char  buf [DESCRIPTION.LINE.LENGTH  +1] ; 


if(/*  Control  line  comes  to  the  upper  side  of  a  box  and  there  */ 
/*  is  a  single  headed  arrow.  */ 

(tem_line->end_position.x  <=  box->swcorner .x  +  BOX.WIDTH)  44 
(teo_line->end_position.x  >=  box->swcorner .x)  44 

(tem_line->end_position.y  >*  box->swcorner .y  -  BOX.HT  -  10)  44 
(tem_line->end_position.y  <*  box->swcorner .y  -  BOX.HT)  44 
((tem_line->end_activity_num  4  (ARROW.HEAD))  !=  0)  44 

((tem_line->end_activity_num  4  (DOT.B.LlDOT.T.R))  ==  0)) 
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{ 

original.line.type  =  get.branchnode(tem.line) ; 
original .l’ ne  *  (struct  line.struct  *) 

f  ind.branchnode (original.line.type) ; 
if (/*  found  a  label  on  the  line  */ 

get_closest_label(original_line,buf ,tem_line->struct_type) 
==  MYTRUE)  { 

Line.labels  =  (struct  text.line.struct  *) 

add_to_inputs_tree(Line_labels ,buf ) ; 

return ; 

> 

if(/*  No  label  on  tem.line  -  Check  if  a  FROM.ALL  exists.  */ 

/*  If  so,  search  TO.ALL  and  get  a  label  for  this  line.  */ 
original_line->start_activity_num  ==  FROM.ALL)  { 
original.line  *  (struct  line.struct  *) 

f ind_TO_ALL_branchnode(original_line->to_from_label) ; 
original_line_type  =  get_branchnode(original_line) ; 
original.line  *  (struct  line.struct  *) 

f ind.branchnode (original.line.type) ; 
if(/*  found  the  branchnode  of  the  TO.ALL  line  segment  */ 
get .closest .label (or iginal. line, buf , line-> struct .type) 

==  MYTRUE)  { 

Line.labels  *  (struct  text. line. struct  *) 

add.to.inputs.tree (Line.labels ,buf ) ; 

return ; 

> 

> 

strcpy(buf ,"") ; 

Line.labels  *  (struct  text.line.struct  *) 

add_to_inputs_tree(Line_labels,buf ) ; 

> 

return ; 

> 
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/*************************************************** ***************** 


*  * 

*  DATE:  19  Feb  1990  * 

*  VERSION:  1.0  * 

*  NAME  :  double_headed_control_with_slash()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  This  module  provides  a  means  of  adding  the  labels  * 

*  of  the  control  arrows  with  double  heads  and  the  * 

*  slash  to  the  linked  list,  Line.labels.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  Line.labels  * 

*  GLOBAL  VARIABLES  CHANGED:  Line.labels  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  get2_closest_label() ,  add.to_inputs_tree()  ,  * 

*  get.branchnodeO ,  f ind_TO_ALL_branchnode() ,  * 

*  f  ind.br  anchnodeO  * 

*  CALLING  MODULES:  check_control_abox()  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY :  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 


*******************************************************************/ 

double_headed_control_with_slash(tem_line) 

struct  line.struct  *tem_line; 

{ 

extern  get2_closest_label() , add.to.inputs.treeO .get.branchnodeO ; 

extern  f  ind.TO.ALL.branchnodeO  .find.br anchnodeO  ; 

struct  line.struct  *original_line; 

char  buf [DESCRIPTION.LINE.LENGTH  +1]; 

int  original.line.type; 

if(/*  Have  a  control  with  a  double  headed  arrow  */ 

(tem_line->end_position.y  <*  box->swcorner .y-B0X_HT)  ftft 
(tem_line->end_position.y  >=  box->swcorner.y-B0X_HT-15)  4ft 
(tem_line->end_position.x  <=  box->swcorner .x+BOX_WIDTH)  ftft 
(tem_line->end_position.x  >*  box->swcorner .x)  ftft 
((tem_line->end_activity_num  ft  (ARROW.HEAD) )  !*  0)  ftft 
((tem_line->end_activity_num  ft  (DOT.B.L))  !=  0)) 

{ 

original.line.type  »  get.branchnode(tem.line) ; 
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original.line  =  (struct  line.struct  *) 

f ind_branchnode(original_line_type) ; 
if (get2_closest_label(original_line,buf ,tem_line->struct_type) 
==  MYTRUE)  { 

Line.labels  ■  (struct  text_line_struct  *) 

add_to_inputs_tree(Line_labels ,buf ) ; 


return; 

} 

if(/*  No  label  on  tem.line  -  Check  if  tem.line  is  a  FROM.ALL  */ 
/*  type  line.  If  so,  search  the  TQ.ALL  and  get  a  label  */ 

/*  from  T0_ALL  line.  */ 

original_line->start_activity_num  ==  FROM.ALL)  { 
original.line  =  (struct  line.struct  *) 

find_TO_ALL_branchnode(original_line->to_from_label) ; 
original_line_type  =  get_branchnode(original_line) ; 
original.line  =  (struct  line.struct  *) 

f ind_branchnode(original_line_type) ; 
if (get2_closest_label(original_line,buf ,line->struct_type) 

==  MYTRUE)  { 

Line.labels  *  (struct  text_line_struct  *) 

add_to_inputs_tree(Line_labels ,buf ) ; 


return; 


> 


> 


strcpy(buf ; 

Line.labels  =  (struct  text_line_struct  *) 

add_to_inputs_tree(Line_labels ,buf ) ; 

> 


return; 

> 
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/******************************************************************** 


*  * 

*  DATE:  20  Feb  1990  * 

*  VERSION:  1.0  * 

*  NAME:  double_headed_control()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  This  module  provides  a  means  of  adding  the  line  * 

*  labels  of  the  control  arrows  with  double  head  to  * 

*  the  linked  list,  Line.labels.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  Line.labels  * 

*  GLOBAL  VARIABLES  CHANGED:  Line.labels  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  Nnone  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  get3_f  irst.labelQ  ,  add.to.inputs.treeO  * 

*  CALLING  MODULES:  check_control_abox()  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 


*******************************************************************/ 
double.headed.control (tem.line) 
struct  line.struct  *tem_line; 

{ 

extern  get3_f  irst.labelO ,  add.to.inputs.treeO  ; 
char  buf [DESCRIPTION.LINE.LENGTH  +1]  ; 

if ((tem_line->start_position.x  <=  box->swcorner .x+BOX_WIDTH+10)  ftft 


(tem.line->start_position .x  >*  box->swcorner .x+BOX_WIDTH)  kk 
(tem_line->start_position.y  <=  box->swcorner .y)  kk 
(tem_line->start_position.y  >~  box->swcorner .y-B0X_HT)  kk 
((tem_line->start_activity_num  k  (ARROW.HEAD) )  !=  0)  kk 


( (tem_line->start_activity_num  k  (DOT.T.R))  !=  0)) 

{ 

if (get3_first_label(tem.line,buf)  ==  MYTRUE)  { 

Line.labels  =  (struct  text.line.struct  *) 

add_to_inputs_tree(Line_labels ,buf ) ; 

return ; 

> 

strcpy(buf ; 

Line.labels  *  (struct  text.line.struct  *) 
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add_to_inputs_tree(Line_labels ,buf ) ; 

> 

return ; 

> 
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/♦♦I********************************************************** ********* 
*  * 

*  DATE:  21  Feb  1990  * 

*  VERSION:  1.0  * 

*  NAME:  check_mechanism_abox()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  This  module  provides  means  of  generating  a  linked  * 

*  list,  Line.labels,  with  all  information  labels  of  the  * 

*  mechanism  arrows  attatched  on  an  activity  box.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  Line.labels  * 

*  GLOBAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  single_headed_mechanism()  * 

*  CALLING  MODULES:  search_labels_touched_abox()  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 

********************************************************************/ 
void 

check_mechanism_abox (tem.line) 
struct  line.struct  *tem_line; 

{ 

extern  struct  text_line_struct  *Line_labels; 

single_headed_mechanism(tem_line) ; 
return; 

> 
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/********************************************************************* 


*  * 

*  DATE:  21  Feb  1990  * 

*  VERSION:  1.0  * 

*  NAME:  single.headed.mechanismO  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  This  module  provides  a  means  of  adding  the  line  * 

*  labels  of  the  mechanism  arrows  with  a  single  head  to  * 

*  a  linked  list,  Line.labels.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  line,  Line.labels  * 

*  GLOBAL  VARIABLES  CHANGED:  Line.labels  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  get.branchnodeO  ,  f  ind.branchnodeO  ,  * 

*  get.closest.labelO ,  f  ind.TO.ALL.branchnodeO  * 

*  add_to_inputs.tr  eeO  * 

*  CALLING  MODULES:  check.mechanism.aboxO  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 


************************************** ****************** ******* *****/ 

single_headed_mechanism(tem_line) 

struct  line.struct  *tem_line; 

{ 

extern  get.branchnodeO  ,f  ind.branchnodeO  .get.closest.labelO  ; 

extern  f ind.TO.ALL.branchnodeO ,add_to_inputs_tree() ; 

extern  struct  line.struct  *line; 

struct  line.struct  *original_line; 

int  original.line.type; 

char  buf [DESCRIPTION.LINE.LENGTH  +1]; 

if ((tem_line->end_position.x  <=  box->swcorner .x+BOX_WIDTH)  Aft 
(tem_line->end_position.x  >=  box->swcorner .x) 
(tem_line->end_position.y  >=  box->swcorner .y)  ftft 

(tem_line->end_position.y  <=  box->swcorner.y+15>) 

original.line.type  =  get.branchnode(tem.line) ; 
original.line  *  (struct  line.struct  *) 

f ind.branchnode (original.line.type) ; 
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if (get_closest_label(original_line,buf ,tem_line->struct_type) 
==  MYTRUE)  { 

Line.labels  =  (struct  text.line.struct  *) 

add_to_inputs_tree(Line_labels,buf ) ; 

return; 

> 

if (original_line->start_activity_num  ==  FROM.ALL)  { 
original.line  =  (struct  line.struct  *) 

f ind.TO.ALL.branchnode (original_line->to_f rom.label) ; 
original_line_type  =  get_branchnode(original_line) ; 
original.line  *  (struct  line.struct  *) 

f ind.branchnode (original.line.type) ; 
if (get.closest. label (or iginal_line,buf ,line->struct .type) 
==  MYTRUE)  { 

Line.labels  =  (struct  text.line.struct  *) 

add_to_inputs_tree(Line_labels,buf ) ; 

return ; 

> 

> 

strcpy(buf , "") ; 

Line.labels  =  (struct  text.line.struct  *) 

add.to. inputs.tree (Line.labels ,buf ) ; 


> 


return ; 

> 
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/*********************************************************************** 


*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  search_labels_touched_abox()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  searching  the  line  * 

*  label  in  accordance  with  the  ICOM  code.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  tem.line  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  Line.labels  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT: None  * 

*  MODULES  CALLED:  check_input_abox() ,  check_output_abox() ,  * 

*  check_control_abox() ,  * 

*  check.mechani  sm^aboxO,  * 

*  CALLING  MODULES:  get.labels.f or..aboxC)  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 


********************************************** ***********************t/ 

search_labels_touched_abox(tem_line , indicator) 
struct  line.struct  *tem_line; 
char  indicator; 

{ 

extern  struct  text_line_struct  *Line_labels ; 

if(tem_line  *=  NULL)  return; 
else  { 

search_labels_touched_abox(tem_line->left .indicator) ; 
search_labels_touched_abox(tem_line->right .indicator) ; 

switch(indicator)  { 
case  ’I’: 

check_input_abox(tem_line) ; 

break; 
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case  ’O': 

check_output_abox(tem_line) ; 
break; 

case  ’C’: 

check_control_abox(tem_line) ; 
break; 

case  ’M’: 

check_mechanism_abox(tem_line) 

break; 

default: 

break; 

> 

> 

return ; 

> 
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/*****+************************************************#*************** 


*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  get.labels.for.abox  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  constructing  a  linked  list  * 

*  (Line.labels)  made  of  the  line  labels  in  accordance  with  * 

*  the  variable,  indicator.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  indicator  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  line.rootnode,  Line.labels  * 

*  GLOVAL  VARIABLES  CHANGED:  Line.labels  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  none  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  search_labels_touched_abox()  * 

*  CALLING  MODULES:  save.arrow.info.of.aboxO  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 


***************************************#****+************************/ 
struct  text.line.struct  * 
get.labels_for.abox (indicator) 
char  indicator; 

{ 

extern  struct  liue.struct  *line_rootnode ; 
extern  struct  text.line.struct  *Line_labels ; 
struct  line.struct  *temporary_line; 

Line.labels  =  NULL; 
temporary. line  =  line.rootnode; 
while  (temporary .line  !=  NULL)  ■{ 

search_label8_touched_abox(temporary_line .indicator) ; 
temporary .line  =  temporary_line->next ; 

> 

return(Line.labels) ; 

> 
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/********************************************************************** 


*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  save.arrow.info.of.aboxO  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  saving  all  information  of  * 

*  arrows (ICOM)  attatched  on  a  box  to  a  file.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  fp,  tem.box  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  box  * 

*  GLOVAL  VARIABLES  CHANGED:  box  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  *.pro,  CHECKBOX. PRO,  or  CHECKBOUNDARY. PRO  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  get_labels_for_abox() ,  fprintfC),  itoaO  * 

*  CALLING  MODULES:  create.temp.box.inf o() ,  traverse_boxes()  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 


*4^******************************************************************/ 

void 

save_arrow_info_of _abox(fp,tem.box) 

FILE  *fp; 

struct  box.struct  *tem_box; 

{ 

extern  itoaO; 

extern  struct  box.struct  *box; 
struct  text_line_struct  *ICQM_labels ; 
char  buf [DESCRIPTION_LINE_LENGTH+l] ; 
int  number.of .input  =  0; 
int  number.of .output  =  0; 
int  number.of .control  *  0; 
int  number.of .mechanism  ■  0; 

/**********  NAME  ***********/ 

fprintf  (f  p ,  "conf  irmed(  [ ’  '/,s  ’ ,  is ,  in.data]  ) .  \n” , 
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tem_box->name. text.string) ; 


/*************  NUMBER  ***********/ 
itoa(tem_box->number,buf ) ; 

fprintf (fp, "confirmed( [' Xs ’ ,number_is , Xs] ) . \n" , 
tem_box->name.text_string,buf ) ; 
box  =  tem.box; 

/*****************  INPUTS  ***414141**********/ 

ICOM_labels  =  (struct  text_line_struct  *)get_labels_f or_abox( ’ I ’ ) ; 
if  (ICOM.labels  ==  NULL)  { 

fprintf (fp, "confirmed ([’Xs’ , input. is .null] ) . \n" , 
tem_box->name. text.string) ; 

} 

else  { 

while (ICOM.labels  !=  NULL)  { 
fprintf  (fp,"conf irmed( [*Xs’ , input _is ,  ’’/.s’] )  An"  , 

tem_box->name. text. string,  ICQM_labels->text_line) ; 
ICOM.labels  *  ICOM_labels->next; 
number.of .input  +=  1; 

> 

itoa (number.of .input ,buf) ; 

fprintf  (fp,  "confirmed  ([’Xs’,  has.input.number,  Xs])An", 
tem_box->name.text_string,buf ) ; 

> 

/********************  OUTPUTS  *************************/ 

ICOM.labels  =  (struct  text.line.struct  *)get_labels_f or_abox( ’0 ’ ) ; 
if  (ICOM.labels  ==  NULL)  { 

fprintf  (fp,"conf  irmed([’X.s'  .output. is  .null] ) .  \n" , 
tem_box->name .text.string) ; 

> 

else  { 

while (ICOM.labels  !=  NULL)  { 
fprintf  (fp,"  confirmed  ([’*/,  s’  .output.is,  ’Xs’])  An", 

tem_box->name .text .string, ICOM.labels ->text_line) ; 
ICOM.labels  =  ICOM_labels->next ; 
number.of .output  ♦=  1; 

> 

itoa(number_of .output, buf) ; 

fprintf  (fp,  "confirmed  (  C’Xs’ ,  has.output.number,  Xs])An", 
tem_box->name. text.string,  buf); 
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/**********************  CONTROLS  **********************/ 

ICOH.labels  =  (struct  text.line.struct  *)get_labels_for_abox( 'C’ ) ; 
if  (ICOH.labels  ==  NULL)  { 

fprintf  (fp,  "conf  irmed(  [  ’'/,s  ’ , control.is .null] ) . \n" , 
tem_box->name .text.string) ; 

> 

else  { 

while (ICOH.labels  !=  NULL)  { 
fprintf  (fp,  "conf  irmed(  [’'/,s  ’ .control.is,  *‘/.s  ’] ) .  \n" , 

tem_box->name . text.string , ICOM_labels->text_line) ; 
ICOH.labels  =  ICOH.labels->next ; 
number.of .control  +=  1 ; 

> 

itoa (number.of .control ,buf) ; 

fprintf  (fp,"  confirmed  ([*'/,  s’ ,  has.control.number ,  '/,s]).\n"t 
tem_box->name. text.string, buf) ; 


/******************  HECHANISHS  ************************/ 

ICOH.labels  *  (struct  text.line.struct  Oget.labels.for.aboxOH’) ; 
if  (ICOH.labels  *=  NULL)  { 

fprintf  (f p ,  "conf  irmed  ( E  ’  ’/.s  ’  .mechanism. is  .null] ) .  \n" , 
tem_box->name. text.string) ; 

> 

else  { 

while (ICOH.labels  !=  NULL)  { 
fprintf  (fp,"confirmed(C’'/,s,  .mechanism.is ,  ’’/.s’])  .\n", 

tem_box->name.t ext _string,ICOH_labels->text .line) ; 
ICOH.labels  =  ICOH_labels->next ; 
number.of .mechanism  +=  1; 

> 

itoa (number.of .mechanism, buf) ; 

fprintf  (fp,  "conf  irmed(  s’ ,  has.mechanism.number ,  ’/,s]).\n", 

tem_box->name. text.string, buf ) ; 

> 

return; 

> 
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/ft********************************************************************* 
*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  create_temp_box_info()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  creating  the  * 

*  temporary  file,  CHECKBOX. PRO,  which  contains  a  set  of  * 

*  predicate  forms  for  an  activity  box.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  found.box  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  None  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  CHECKBOX. PRO  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  fopenO  ,  put.messageO  ,  di  sable,  input  .window  () ,  * 

*  save.header.infoO ,  save .arrow. inf o.of _abox() ,  * 

*  fcloseQ,  printfO  * 

*  CALLING  MODULES:  f ind.clicked.boxO  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 

*********************************************************************/ 
void 

create.temp.box. info (found.box) 
struct  box.struct  *found_box; 

{ 

extern  put.messageO ,disable_input.window() ; 

FILE  *fp; 

if((fp  =  f open ( "CHECKBOX . PRO " , "w" ) )  ==  NULL)  { 
put .messaged ."Unable  to  open  the  CHECKBOX. PRO  file  —  ABORT."); 
disable.input.windowO ; 

> 

else  { 

disable.input.windowO ; 

8ave_header_info(fp) ; 
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save_arrov_info..of  _abox(fp,found_box) ; 

if (f close(fp)  !*  0)  printf ("FILE  CLOSE  FAILEDNn"); 

> 

return ; 

> 
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/********************************************************************** 


*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  f  ind.clicked.boxQ  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  checking  if  there  is  a  box  * 

*  within  the  cordinate(x ,y)  clicked  by  the  user  mouse.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  x,y  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  box.rootnode  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  put.messageQ ,  create.temp.box.infoQ ,  * 

*  my.window.setO ,  null.procO  * 

*  CALLING  MODULES:  check.button.f or.activity O  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  CRDER  OF  :  * 


it********************************************************************/ 

void 

f ind_clicked_box(x,y) 
int  x,y ; 

{ 

extern  put_message()  .my.window.setO  , null.procO  ; 
extern  struct  box.struct  *box_rootnode; 
struct  box.struct  *bbox; 

bbox  *  box.rootnode; 
while  (bbox  !=  NULL)  { 

if(x  >*  bbox->8wcorner .x  Aft  x  <■  bbox  >swccrner.x  +  BOX.WIDTH  AA 
y  >=  bbox->swcorner .y  -  BOX.HT  Aft  y  <=  bbox->swcorner .y) 

put .messaged ."Enter  the  prolog  environment 
using  another  window."); 
create_temp_box_info(bbox) ; 
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my_windotf_set(null_proc) ; 
return ; 

> 

bbox  =  bbox->next; 

> 

put_message(l, "Box  not  found  -  Try  again(|L|  to  select)"); 
return ; 

> 
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/ft********************************************************************* 


*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  check_button_for_activity()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  checking  the  button  clicked* 

*  by  user  mouse  if  the  clicked  button  is  right  or  left.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  window,  event,  arg(Sun  variable)  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  window,  event,  arg  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  event_id(),  f ind_clicked_box() ,  event_x(),  * 

*  event.yO,  my_vindow_set() ,  null.procO,  * 

*  put.messageO  * 

*  CALLING  MODULES:  check. activity ()  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 


*********************************************************************/ 

void 

check_button_f or.activity (window, event , arg) 

Window  window; 

Event  *event ; 
caddr.t  arg; 

{ 

extern  my.window.setO  ; 

extern  put_message() ,  null_proc(); 

/*  Check  for  left  or  right  button  */ 
switch(event_id(event) )  { 

case  MS.LEFT : 

if (event_is_up(event) ) 

f ind_clicked_box(event_x(event) ,event_y (event)) ; 
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break; 


case  MS. RIGHT : 

my_window_set(null_proc) ; 

put_message(l ."ABORT  —  Make  another  selection."); 
break; 

default : 
break; 

> 

return ; 

> 
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/********************************************************************** 


*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  check.activityO  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  finally  producing  a  file  * 

*  contained  a  set  of  predicate  forms  for  an  activity  box.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  None  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  header.rootnode ,  box.rootnode  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  put_message() ,  strcmpO ,  my_move_cursor() ,  * 

*  my.window.setO  * 

*  CALLING  MODULES:  make.windows O  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 


*********************************************************************/ 

void 

check.activityO 

{ 

extern  put_message() ,  my.window.setO,  my_move_cursor() ; 
extern  struct  box_struct  *box_rootnode ; 
extern  struct  header.struct  *header_rootnode ; 

if (box.rootnode  ==  NULL)  { 

put .messaged , "FATAL:  Can’t  check  this  empty  diagram 
—  Make  another  selection."); 
return; 

> 

if (strcmp(header_rootnode->title.text_string,"")  ==  0)  { 
put.messageCl , "NO  TITLE:  Please  enter  the  TITLE 
using  EDIT  DGM  and  then  RETRY!!!"); 
return; 
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} 

my .move .cursor (INIT.LOC.X , INIT_L0C_Y) ; 

my_window_set(check_button_f or. activity) ; 

put .messaged ."Move  cursor  inside  activity  box 
and  click  left  button  -  Right  to  ABORT."); 
return ; 

> 
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/^^4******************************************************************* 
*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  create_temp_boundary_info()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  saving  all  information  of  * 

*  boundary  arrows  of  the  IDEFO  diagram  into  the  tempory  * 

*  file  CHECKBOUNDARY. PRO.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  parentfile  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  header.rootnode  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  parentfile  * 

*  FILES  WRITTEN:  CHECKBOUNDARY . PRO  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  fopenO ,  put.messageQ  ,  disable_input_window()  * 

*  getcO,  putcQ,  fcloseO,  search.boundary. inf o()  ,* 

*  save.null.boundaryO  ,  printfQ  * 

*  CALLING  MODULES:  check.parent.box.f ile()  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 

*#******************************#************************************/ 
void 

create.temp.boundary. info (parentfile) 
char  parentfile [] ; 

{ 

extern  put.messageO ,disable_input_windov() ; 

FILE  oparentfp,  fchildfp; 

extern  struct  header.struct  *header_rootnode ; 
extern  int  number.of .boundary. input .number.of .boundary. output ; 
extern  int  number.of .boundary.control .number.of .boundary.mechanism; 
int  ch; 

number. of .boundary. input  =  0; 
number.of .boundary.output  =  0; 
number.of .boundary.control  *  0; 
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number _of .boundary .mechanism  =  0; 
if((parentfp  =  fopen(parentf ile, "r"))  =!s  NULL  l| 

(childfp  =  f open ("CHECKBOUNDARY. PRO" , "w"))  ==  NULL)  { 
put_message(l , "Unable  to  open  the  predicate  file(s)  —  ABORT"); 
disable.input.windowQ ; 

> 

else  { 

disable.input.windovO ; 

»hile((ch  =  getc(parentfp))  !=  EOF) 
putc(chf childfp) ; 
fclose(parentfp) ; 
search.boundary.inf o(childfp) ; 
save.null.boundary(childfp) ; 

if (fclose(childfp)  !=  0)  printfO'FILE  CLOSE  FAILED\n") ; 

> 

return ; 

> 
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/*>M*******4^******************************************* ******* ******** 


*  * 

*  DATE:  IS  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  check_parent_box_file()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  checking  if  there  is  the  * 

*  file  which  the  user  specifies  in  the  current  directory.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  None  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  None  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  strcpyO,  panel_get_value() ,  fix_input(),  * 

*  strcmpO,  put.messageO  ,  disable_input_window() ,  * 

*  strcatO,  check_f  ilenameQ ,  * 

*  create_temp_boundary_info()  * 

*  CALLING  MODULES:  check_button.for_boundary ()  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 


*********************************************************************/ 
check_parent_box_f ile ( ) 

{ 

extern  put_message() .  disable_input_windov() ,check_f ilenameQ ; 
extern  my_move_cursor() ,my_windov_set() ,fix_input() ; 
char  name [FILE.NAME. LENGTH  +  1] ,name2 [FILE.NAME.LENGTH  +  5]; 
int  f ile_type_indicator ; 

strcpy(name,(char  *)panel_get_value(input_item) ) ; 
f ix_input(name) ; 
if (strcmp(name,"")  »*0)  { 

put_message(l ."ABORT:  No  file  name  received 
--Make  another  selection."); 
disable_input_window() ; 
return (PANEL.NONE); 
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> 

strcpy(name2,name) ; 
strcat (name2 , " . pro" ) ; 

f ile.type.indicator  =  check.f ilename(name2) ; 
switch  (f ile.type.indicator)  { 

case  -1: 

disable.input.windowQ ; 
put  .messaged,  "ABORT:  File  does  not  exist 
— Make  another  selection."); 
break; 

case  -3: 

disable.input.windowQ ; 
put.messaged , "ABORT:  File  is  a  directory 
—  Make  another  selection."); 
break; 

case  -2:  /*  READ  ONLY  */ 
case  0:  /*  READ/WRITE..  */ 

put .message (1, "Enter  prolog  environment  using  another  window."); 
create.temp_boundary_info(name2) ; 
break ; 

default : 

put.messaged , "Unknown  condition  --  Make  another  selection."); 

disable.input .window () ; 

break; 

> 

return (PANEL.NONE) ; 

> 
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/********************************************************************** 
*  * 

*  DATE:  IS  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  check_button_for_boundary()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  conforming  if  the  user  * 

*  would  like  to  be  continue  to  check  IDEFO  syntax  for  the  * 

*  boundary  arrows  in  any  IDEFO  diagram.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  window,  event,  arg(Sun  variables)  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  None  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  event_is_up() ,  event.idQ ,  enable. input _window() ,* 

*  panel.setO,  check_parent_box_f  ileO ,  * 

*  put_message() ,  my_window_set() ,  null.procQ  * 

*  CALLING  MODULES:  check_boundary()  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 

*********************************************************************/ 
void 

check.button.f or.boundary (window, event ,arg) 

Window  window; 

Event  *event; 
caddr.t  arg; 

{ 

extern  put_message() ,enable_input_window() ,my_window_set() ; 
extern  null.procC); 

if (event_is_up(event))  return; 

switch  event. id(event) 

■C 

case  MS.LEFT: 
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enable. input .window () ; 
panel_set( input. item, 

PANEL. VALUE.STDRED.LENGTH , FILE.NAME.LENGTH , 
PANEL.NOTIFY.PROC ,  check.parent.box.f ile , 

0); 

put  .messaged,  "Enter  the  predicate  file  NAME 
with  parent  box  and  hit  <Return>."); 
break; 

case  MS.RIGHT : 
my_windov_set(null_proc) ; 

put  .messaged,  "OPERATION  ABORTED  --  Make  another  selection.1 
break; 

default:  break; 

> 

return; 

> 
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/********************************************************************** 
*  * 

*  DATE:  IS  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  check.boundaryO  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  producing  all  information  * 

*  of  a  set  of  predicate  forms  of  the  boundary  arrows  in  the  * 

*  IDEFO  diagram  so  as  to  check  IDEFO  syntax  of  boundary  * 

*  arrows .  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  None  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  header.rootnode , line.rootnode  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  disable.  input.windowO  ,  put_message()  ,  strcmpO,  * 

*  my.move.cursorO,  my.window.setO  * 

*  CALLING  MODULES:  make.windowsO  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 

******************************** ********************************/ 

void 

check.boundaryO 

{ 

extern  put.messageO  , my.window.setO  ; 
extern  my.move.cursorO ,disable_input_window() ; 
extern  struct  box.struct  *box_rootnode; 
extern  struct  line.struct  *line_rootnode; 
extern  struct  header.struct  *header_rootnode; 

if (box.rootnode  ==  NULL)  { 
disable.input.windowO ; 

put_message(l, "FATAL:  Can’t  check  this  empty  diagram 
—  Make  another  selection."); 
return; 
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> 

if  (line.rootnode  ==  NULL)  ■( 
put  .messaged,  "FATAL:  Can’t  check  this  diagram 
—  Make  another  selection."); 
disable. input .window () ; 
return ; 

> 

if (strcmp(header_rootnode->title.text_string,"M)  ==  0)  { 
put.messaged » "NO  TITLE:  Please  enter  the  TITLE  using  EDIT  DGM 
and  then  RETRY! ! !") ; 
disable.input.windowO ; 
return ; 

> 

put .messaged ."CHECK  BOUNDARY  ARROW  :  |L|  to  check  -  |R|  to  ABORT"); 
my .move. cursor (INIT.LOC.X , INIT.LDC.Y) ; 
my_window_set(check_button_for_boundary) ; 
return; 

> 
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/********************************************************************** 
*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  save.null.boundaryO  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  saving  the  information  * 

*  which  contains  that  there  is  no  boundary  arrow  in  * 

*  accordance  with  ICOM.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  fp(file  pointer)  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  number.of .boundary.input ,  * 

*  number_of_boundary_output ,  * 

*  number. of _boundary_control ,  * 

*  number.of .boundary .mechanism  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  fp  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  fprintfC),  itoaQ  * 

*  CALLING  MODULES:  create.temp.boundary.infoC)  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 

?********************************************************************/ 
save.null.boundary(fp) 

FILE  *fp; 

{ 

extern  int  number.of .boundary.input , number.of .boundary.output ; 
extern  int  number.of .boundary .control, number.of .boundary .mechanism; 
extern  itoa(); 

char  buf [DESCRIPTION.LINE.LENGTH+1] ; 

if  (number.of .boundary.input  ==  0) 

fprintf (fp,,,confirmed([boundary_input,  is,  null]).\n"); 
if  (number.of .boundary.output  ==  0) 

fprintf (fp,"confirmed( [boundary.output,  is,  null]).\n"); 
if  (number.of .boundary .control  ==  0) 
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fprintf (fp,"confirmed([boundary_control,  is,  null]).\n"); 
if  (number.of .boundary .mechanism  ==  0) 

fprintf (fp,"conf irmed( [boundary .mechanism,  is,  null]).\n"); 
itoa(number_of .boundary, input ,buf ) ; 

fprintf  (fp,"conf irmed( [boundary. input ,  has.number,  */,s]  ) . \n"  ,buf ) ; 
itoa (number .of .boundary .output ,buf ) ; 

fprintf  (fp,"confirmed([boundary_output,  has.number,  */,s])  .\n",buf) ; 
itoa(number_of_boundary_control ,buf ) ; 

fprintf  (fp,"confirmed( [boundary.control,  has.number,  */,s]  )  .\n",buf) ; 
itoa(number_of_boundary_mechanism,buf ) ; 

fprintf  (fp,"confirmed( [boundary .mechanism,  has.number,  */,s]  ) .  \n"  ,buf ) ; 
return(MYTRUE) ; 

> 
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/********************************************************************** 
*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  search_NLR_boundary_line_info()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  working  through  the  * 

*  tree  of  line  structure  in  left  and  right  direction.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  line.info,  fp  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  None  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  save_boundary_line_inf o() ,  * 

*  search_NLR_boundary_line_info()  * 

*  CALLING  MODULES:  search.boundary.inf o()  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 

*********************************************************************/ 

void 

search.NLR_boundary_line.inf o (line.info ,fp) 
struct  line_struct  *line_info; 

FILE  *fp; 

{ 

extern  int  number.of .boundary.input .number.of .boundary.output ; 
extern  int  number.of .boundary.control , number.of .boundary .mechanism; 

if(line_info  ==  NULL)  return; 
else 
{ 

save_boundary_line_inf o(line_ inf o ,f p) ; 
search_NLR_boundary_line_info(line_info->lef t ,f p) ; 
search.NLR. boundary .line. inf o (line, inf o->right , fp) ; 

> 

return; 


F-56 


F-57 


/********************************************************************** 


*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  search_boundary_info()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  working  through  the  * 

*  tree  of  the  line  structure  in  next  direction.  * 

*  ALGORITHM :  * 

*  PASSED  VARIABLES:  fp  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  line_rootnode  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  fprintfQ,  search_NLR_boundary_line_info()  * 

*  CALLING  MODULES:  create_temp_boundary_info()  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 


***^*******>m********************************************************/ 

search_boundary_info(fp) 

FILE  *fp; 

{ 

extern  struct  line.struct  *line_rootnode ; 
struct  line_struct  *line_info; 

extern  int  number.of .boundary.input ,number_of _boundary_output ; 
extern  int  number.of _boundary_control ,number_of .boundary .mechanism; 

fprintf  (fp,"conf irmed( [child.title ,  is,  ’V,s’]).\n", 
header_rootnode->title .text.string) ; 
line.info  =  line.rootnode ; 
while(line_info  !=  NULL) 

{ 

search_NLR_boundary_line_info (line.info, fp) ; 
line.info  *  line.inf o->next ; 

> 

return (MYTRUE) ; 
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/********************************************************************* 

*  * 

*  DATE  :  4  Feb  1990  * 

*  VERSION  :  1.0  * 

*  * 

*  NAME  :  save_boundary_line_info()  * 

*  MODULE  NUMBER  :  * 

*  DESCRIPTION  :  * 

*  This  module  is  to  save  the  information  of  the  boundary  * 

*  arrows  in  the  IDEFO  diagram.  * 

*  ALGORITHM  :  * 

*  PASSED  VARIABLES  :  line.info,  fp  (File  Pointer)  * 

*  * 

*  RETURNS  :  None  * 

*  GLOBAL  VARIABLES  USED  :  None  * 

*  GLOBAL  VARIABLES  CHANGED  :  None  * 

*  FILES  READ  :  None  * 

*  FILES  WRITTEN  :  fp  * 

*  HARDWARE  INPUT  :  None  * 

*  HARDWARE  OUTPUT  :  None  * 

*  MODULES  CALLED  :  itoaQ ,  fprintfO  * 

*  CALLING  MODULES  :  search.NLR_boundary_line.inf o()  * 

*  * 

*  AUTHOR  :  Intaek  Kim  * 

*  HISTORY  :  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 

***4^4^*************************************************************/ 

save.boundary.line. info (line. inf o,fp) 
struct  line.struct  *line_info; 

FILE  *fp; 

{ 

extern  itoaQ  ; 

extern  int  number.of .boundary.input .number.of .boundary.output ; 
extern  int  number.of _boundary_control ,number_of .boundary .mechanism; 
char  buf [DESCRIPTION.LINE.LENGTH+l] ; 

switch(line_info->start_ICOM[0] ) 

{ 

case  ’ I ’  : 

number.of .boundary. input  +«  1; 
itoaCnumber.of .boundary .input ,buf ) ; 

fprintf (fp ,"conf irmed( [boundary_input'/,s ,  is,  ,V.s’]).\n", 
buf ,line_info->label .text.string) ; 
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break; 


case  ’C*: 

number.of .boundary.control  +=  1; 
itoa(number_of .boundary.control, buf ) ; 
fprintf (fp,  "confirmed(  [boundary  _control'/.s ,  is,  ’’/.s'] 
buf ,line_info->label .text.string) ; 

break; 
case  ’M’: 

number.of .boundary .mechanism  +=  1; 
itoa(number_of .boundary .mechanism, buf ) ; 
fprintf (fp,"conf irmedC [boundary .mechanism'/, s,  is,  ’‘/.s’ 
buf  ,line_info->label.text_string) ; 

break ; 
default : 

if  (line_info->end_ICOM[0]  s=  *0’) 

{ 

number.of .boundary.output  +=  1 ; 
itoa(number_of .boundary.output ,buf ) ; 
fprintf  (fp,"conf  irmedC  [boundary. output'/,s,  is,  ’’/,s 
buf , line.inf o->label . text.string) ; 

break; 

> 

> 

return (MYTRUE) ; 

} 
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) . \n" , 


] )  •  \n"  , 


’] ) . \n" , 


/ft******************************************************************** 
*  * 

*  DATE  :  2  Feb  1990  * 

*  VERSION  :  1.0  * 

*  * 

*  NAME  :  save_header_info()  * 

*  MODULE  NUMBER  :  * 

*  DESCRIPTION  :  * 

*  This  module  is  to  save  the  information  of  "NODE"  and  * 

*  "TITLE"  in  the  IDEFO  diagram.  * 

*  * 

*  ALGORITHM  :  * 

*  PASSED  VARIABLES  :  fp  (File  pointer)  * 

*  * 

*  RETURNS  :  None  * 

*  GLOBAL  VARIABLES  USED  :  header.rootnode  * 

*  GLOBAL  VARIABLES  CHANGED  :  None  * 

*  FILES  READ  :  None  * 

*  FILES  WRITTEN  :  fp  * 

*  HARDWARE  INPUT  :  None  * 

*  HARDWARE  OUTPUT  :  None  * 

*  MODULES  CALLED  :  fprintfO  * 

*  CALLING  MODULES  :  store.predicatesO  * 

*  * 

*  AUTHOR  :  Intaek  Kim  * 

*  HISTORY  :  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 

********************************************************* ***********/ 

save.header.info(fp) 

FILE  *fp; 

{ 

extern  put.messageO ,disable_input_windov() ; 
extern  struct  header_struct  *header_rootnode ; 

fprintf  (fp,"conf irmed( [title,  is,  ’7, s’])  .\n", 
header_rootnode->title. text. string) ; 
fprintf (fp,"conf irmed( [node,  is,  ’7,s’]).\n", 
header_rootnode->node .text.string) ; 
remraCMYTRUE)  ; 

> 
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/*****#**************************************************************** 


*  * 

*  DATE:  20  Feb  1990  * 

*  VERSIOIN :  1.0  * 

*  * 

*  NAME:  traverse.boxesO  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION :  * 

*  This  module  provides  a  means  of  traversing  all  the  * 

*  activity  boxes  in  a  diagram  and  of  passing  the  * 

*  information  of  each  box  to  store_diagram() .  * 

*  * 

*  ALGORITHM :  * 

*  PASSED  VARIABLES:  fp  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  box.rootnode  * 

*  GLOBAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  s ave. arrow. info. of _abox()  * 

*  CALLING  MODULES:  store.predicatesC)  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 


*********************************************************************/ 

void 

traverse.boxes (f p) 

FILE  *fp ; 

{ 

extern  struct  box.struct  *box_rootnode; 
struct  box.struct  *temp_box; 

temp.box  =  box.rootnode; 
while(temp_box  !=  NULL) 

{ 

save.arrow.info.of _abox(fp .temp.box) ; 
temp.box  =  temp_box->next ; 

> 

return ; 

> 
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/it******************************************************************* 


*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  store.predicatesO  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  saving  all  information  of  * 

*  arrows dCOM)  attatched  on  the  activity  boxes  in  the  IDEFO  * 

*  diagram.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  file.name  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  None  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  fopenO,  put_message() ,  disable.input.windowO,  * 

*  save.header.infoO  ,  traverse_boxes() ,  fcloseQ  * 

*  CALLING  MODULES:  overwrite.predictesO  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 


*****  .*************************************************************/ 
void 

store_predicates (file.name) 
char  file.nameD; 

{ 

extern  put.messageO ,disable_input_window() ; 

FILE  *fp; 

if  ((fp  *  fopenCf ile_name,"w"))  ==  NULL)  { 

put .messaged , "Unable  to  open  the  file  for  predicates 
—  ABORT."); 
disable.input.windowO ; 

> 

else  { 

disable.input.windowO  ; 
save.header.info(fp) ; 
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traverse_boxes(fp) ; 

if (fclose(fp)  !=  0)  printf ("FILE  CLOSE  FAILED\n") ; 

> 


return ; 

> 
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/********************************************************************** 


*  * 

*  DATE:  15  Feb  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  overwrite.predicatesO  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  overwriting  the  predicate  * 

*  forms  into  the  existing  flie  which  is  specified  by  the  user* 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  window,  event,  arg(Sun  variables)  * 

*  * 

*  RETURNS:  None  * 

*  GLOBAL  VARIABLES  USED:  last.f ile.name  * 

*  GLOVAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  file  pointer  passed  to  a  .pro  file  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  event_is_up() ,  event.idQ ,  strcpyO,  * 

*  store_predicates() ,  put.messageO ,  null_proc(),  * 

*  my.window.set O  * 

*  CALLING  MODULES:  get_f ilenarae_for_predicates()  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE  :  * 

*  ORDER  OF  :  * 


*********************************************************************/ 

void 

overwrite.predicates (window , event , arg) 

Window  window; 

Event  *event ; 
caddr.t  arg; 

{ 

extern  null_proc(),  put.messageO ,my_window_set() ; 
char  f ile.name [FILE.NAME.LENGTH  +  5]; 

if  (!event_is_up(event))  return; 
switch(event_id(event) ) 
t 

case  MS.LEFT: 

strcpyCf ile.name, last.f ile.name) ; 
store. predicates (f ile.name) ; 
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put .messaged ."OVERWRITE  DONE  —  Make  another  selection.”); 

my_windov_set(null_proc) ; 

break; 


case  MS.RIGHT: 
my_window_set(null_proc) ; 

put.messageCl , "ABORT  overwrite  —  Make  another  selection."); 
break ; 

> 


return ; 

> 
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/********************************************************************* 
*  * 

*  DATE:  10  Jan  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  get_f ilename_for_predicates ()  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  The  purpose  of  this  module  is  to  get  the  file  name  from  the  * 

*  user  in  which  to  save  the  predicates  file.  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  None  * 

*  RETURNS:  PANEL.NONE  (Sunviev  variable)  * 

*  GLOBAL  VARIABLES  USED:  None  * 

*  GLOBAL  VARIABLES  CHANGED:  None  * 

*  FILES  READ:  None  * 

*  FILES  WRITTEN:  None  * 

*  HARDWARE  INPUT:  None  * 

*  HARDWARE  OUTPUT:  None  * 

*  MODULES  CALLED:  put_message() ,f ix_input() ,disable_input_window() ,* 

*  check_f ilenameQ ,my_window_set 0 ,stordicates() ,  * 

*  my_move_cursor() ;  * 

*  CALLING  MODULES:  save.predicatesQ  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY:  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 

********************************************************+************/ 
Panel_setting 

get_f ilename.f or_predicates() 

•c 

extern  put_message() ,disable_input_window() ; 
extern  fix_input(),  my_window_set () ,my_move_cursor() ; 
extern  check.f  ilenameO  ; 

char  name[FILE_NAME_LENGTH+l] ,name2 [FILE_NAME_LENGTH+5] ; 
int  f ile_type_indicator ; 


/*  get  the  user  input (file  name)  */ 

strcpy(name, (char  *)panel_get_value(input_item) ) ; 

f ix.input(name) ;  /*  Remove  blanks  and  replace  \n  to  \0  */ 

if (strcmp(namet"M)==0) 

{ 

put.message(l , "OPERATION  ABORTED  --  NO  FILE  NAME  RECEIVED 


—  Make  another  selection"); 
disable.input.windowO ; 
return (PANEL.NONE) ; 

> 

strcpy(name2,name) ; 
strcat(name2," .pro") ; 

/*  Checks  file  name  of  "narae2"  is  what  type  of  file.  */ 
f ile.type.indicator  =  check.f ilename(name2) ; 

switch(file_type_ indicator) 

{ 

case  -1: 

store_predicates(name2) ; 

put .messaged , "SAVE  DONE  —  Make  another  selection."); 
break; 
case  -2: 

disable_input_vindow() ; 

put .messaged , "Can’t  overwrite  file  —  READ  ONLY 
—  Make  another  selection."); 
break; 
case  -3: 

disable_input_window() ; 

put_message(l,"File  is  a  DIRECTORY  —  Make  another  selection."); 
break ; 
case  0: 

put.messaged , "FILE  EXISTS  -  III  to  overwrite,  -  |R|  to  ABORT."); 
my.move.cursor (INIT.LOC.X , INIT.LOC.Y) ; 
strcpy(last_f ile.name ,name2) ; 
my _window_set (overwrite. predicates) ; 
break; 
default : 

put.messaged , "Unknown  condition  —  Make  another  selection"); 

disable.input.windowO  ; 

break; 

> 

return (PANEL.NONE) ; 

> 
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/*********************************************************************** 


*  * 

*  DATE:  10  Jan  1990  * 

*  VERSION:  1.0  * 

*  * 

*  NAME:  save.predicatesO  * 

*  MODULE  NUMBER:  * 

*  DESCRIPTION:  * 

*  This  module  provides  a  means  of  asking  user  for  continuing  to  * 

*  save  a  predicate  file(.pro)  or  to  abort  this  function.  * 

*  * 

*  ALGORITHM:  * 

*  PASSED  VARIABLES:  * 

*  * 

*  GLOBAL  VARIABLES  USED:  *box_rootnode ,  *header_rootnode  * 

*  GLOBAL  VARIABLES  CHANGED: None  * 

*  FILES  READ:  * 

*  FILES  WRITTEN:  * 

*  HARDWARE  INPUT:  * 

*  HARDWARE  OUTPUT:  * 

*  MODULES  CALLED:  get_f ilename_for_predicates()  * 

*  CALLING  MODULES:  make.vindovs 0  * 

*  * 

*  AUTHOR:  Intaek  Kim  * 

*  HISTORY  :  * 

*  ABSTRACT  DATA  TYPE:  * 

*  ORDER  OF:  * 


*********************************** *************************** ********/ 
void 

save.predicates ( ) 

{ 

extern  put_message() ,  enable.input.windowC) ; 
extern  disable_input_window() ; 
extern  struct  box.struct  *box_rootnode; 
extern  struct  header.struct  *header_rootnode ; 

if (box.rootnode  ==  NULL)  { 

put.messageCl , "FATAL:  Can’t  save  this  empty  diagram 
—  Make  another  selection."); 
disable.input.windovC) ; 
return; 

> 

if (strcmp(header_rootnode->title.text_string,"M)  ==  0)  { 
disable. input. windowQ  ; 

put.messageCl, "NO  TITLE:  Please  enter  the  TITLE 
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using  EDIT  DGM  and  then  RETRY!!"); 
return; 

> 

enable_input_windov() ; 
panel. set (input .item, 

PANEL. VALUE_STORED_LENGTH,FILE_NAME_LENGTH, 
PANEL.NOTIFY.PROC ,  get.f ilename.f or.predicates , 

o); 

put  .messaged,  "Enter  the  file  name  and  hit  <Return>."); 
return ; 

> 
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IDEFq  Syntax  Expert  System 

This  section  presents  the  source  code  documentations  for  the  IDEFo  Syntax 
Expert  System  and  contains  the  inference  engine(ISES)  and  two  rule  bases:  Activity 
IDEFo  Syntax  Rules  and  Boundary  IDEFq  Syntax  Rules. 
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Inference  Engine 


/*************************************************************** 

*  * 

*  DATE:  25  Feb.  1990  * 

*  VERSION:  1.1  * 

*  NAME:  BC3  * 

*  DESCRIPTION:  The  purpose  of  this  module  is  to  provide  an  * 

*  inference  engine  for  checking  IDEFO  syntax.  * 

*  BC3  provides  a  means  of  a  shell  for  backward  * 

*  chaining  control  strategy.  * 

*  OPERATING  SYSTEM:  UNIX  4.3  * 

*  LANGUAGE:  Quintus  Prolog  * 

*  CONTENTS:  *  * 

*  AUTHOR:  DR.  Frank  M.  Brown  * 

*  HISTORY:  Version  1.0  -  MS-DOS  vers  ion (DR.  Frank  M.  Brown)  * 

*  Version  1.1  -  UNIX  4.3  vers ion (Intaek  Kim)  * 

*************************************************************** 

/***************************************************************/ 
/*  */ 

/*  BC3  */ 

/*  */ 

/*  A  shell  for  backward-chaining  expert  systems.  */ 

/*  */ 

/*  Each  item  of  knowledge  is  represented  by  a  triple,  i.e.,  */ 

/*  a  three-element  list  of  the  form  [Object .Attribute, Value] .  */ 
/*  */ 

/*  An  associated  rule-base  supplies  the  following  data:  */ 

/*  */ 

/*  1.  A  goals-statement ,  in  the  form  of  a  list  of  triples  to  */ 

/*  be  solved  in  sequence.  The  solved  triples  are  printed  */ 
/*  by  the  shell.  */ 

/*  2.  A  collection  of  if-then  rules  for  triples.  */ 

/*  3.  A  collection  of  ’fact’  triples,  i.e.,  triples  asserted  */ 

/*  as  known  a  priori.  */ 

/*  4.  A  collection  of  ’askable*  triples,  indicating  the  forms  */ 

/*  of  triples  whose  values  may  be  obtained  from  the  user.  */ 
/*  5.  A  collection  of  ’keep’  triples,  indicating  the  form  of  */ 

/*  the  triples  not  to  be  erased  from  working  memory  at  */ 
/*  the  beginning  of  a  new  session.  */ 

/*  */ 

/*  Each  item  of  knowledge  stored  in  working  memory  is  of  the  */ 
/*  form  conf irmed( [Obj ,Attr,Val])  or  denied( [Obj ,Attr,Val] ) .  */ 

/*  */ 

/*  To  use  the  system,  load  BC3,  load  the  appropriate  rule-  */ 
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/*  base  and  type  ’start.’  Because  BC3's  operator-def ini-  */ 

/*  tions  are  used  by  the  rule-bases,  BC3  must  load  first.  */ 

/*  */ 

/*— . OPERATOR  DEFINITIONS . . . */ 

/*  */ 

/*  The  operators  defined  below  enable  the  rules  in  the  know-  */ 
/*  ledge-base  to  be  expressed  in  a  form  more  readable  than  */ 
/*  the  standard  (prefix)  form.  */ 

/*  */ 

/* . - . . */ 


?-  op (250,  xfx,  : : ) . 

?-  op(245,  xfx,  then). 

?-  op (240,  fx,  if). 

?-  op (235,  xfx,  derived.f rom) . 

?-  op(230,  xfy,  or). 

?-  op(225,  xfy,  and). 

?-  op (220,  fy,  not). 


/* . START . */ 

/*  */ 

/*  The  procedure  ’start’  begins  by  erasing  from  working  mem-  */ 
/*  ory  all  ’confirmed’  and  ’denied’  clauses,  except  those  */ 

/*  clauses  protected  by  ’keep’  from  erasure.  The  list  of  */ 

/*  goal-triples  is  then  read  from  the  rule-base  and  solved  in  */ 
/*  turn  by  ’solve’.  A  trace  is  maintained  of  the  back-  */ 

/*  chaining  search-tree  generated  in  solving  the  goals.  When  */ 

/*  the  last  of  the  goal-triples  is  solved,  the  values  of  all  */ 
/*  goals,  except  those  solved  by  asking  the  user  directly,  */ 
/*  are  displayed;  the  trace  is  also  displayed,  if  requested,  */ 
/*  as  a  "how"  explanation  of  the  solution.  */ 

/*  */ 


erase. working.memory  : - 

(  confirmed (Triple) ,  /*  Erase  all  working-mem-  */ 

not (keep : :Triple) ,  /*  ory  elements  not  pro-  */ 

retract (conf irmed(Triple) )  /*  tected  by  ’keep’  state-*/ 

;  /*  ments  in  the  knowledge-*/ 

denied (Triple) ,  /*  base.  */ 

not(keep: ;Triple) , 
retract (denied(Triple))  ), 
fail . 
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erase.working.memory . 


start  :- 

ask_about_verbose , 
fail. 

start 


ask_ about .checking .type , 


fail. 

start  :- 

retractall (why. trace (_ ) ) , 

/*  Erase  the  "why"  trace.  */ 

goals::  Goals, 

/*  Find  the  goal-triples ,  */ 

pref ix(Goals ,Pref ixedGoals) , 

/*  prefix  each  of  them  */ 

show.head.message , 

/*  with  the  word  ’goal’,  */ 

solve(Goals, [] .PartTrace) , 

/*  satisfy  all  of  the  */ 

!  ,nl, 

/*  goals  and  then  put  the  */ 

append(Pref ixedGoals .PartTrace .Trace) , 

/*  list  of  goals  at  the  */ 

/*  front  of  the  "how"  */ 

ask.about.trace (Trace) , 

/*  trace.  Supply  a  "how"  */ 

ask. about _  saving. working.memory , 
erase.working.memory , 
start.message. 

/*  explanation  on  request.*/ 

start  :- 

/*  If  all  triples  can’t  */ 

nl. 

/*  be  solved,  announce  it.*/ 

write(’I  can”t  solve  this  problem 

•  ’ ) ,nl , 

start .message. 


/* . . SOLVE . - . */ 

/*  */ 

/*  The  predicate  ’ solve(Goals, Trace, New.trace) ’  means  that  */ 
/*  Goals  is  a  list  of  goals  (expressed  as  triples),  and  that  */ 
/*  Trace  and  New.trace  sure,  respectively,  the  trace-lists  be-  */ 
/*  and  after  solution  of  the  goal  at  the  head  of  the  goal-  */ 
/*  list.  The  procedure  ’solve'  solves  each  of  the  goals  in  */ 
/*  turn.  The  first  step  in  solving  a  goal  is  to  erase  the  */ 
/*  "why"  trace  and  to  initialize  it  with  that  goal.  Thus  each  */ 
/*  goal  is  solved  with  a  separate  "why"  trace.  As  each  rule  */ 
/*  is  encountered  in  descending  through  the  search-tree  for  a  */ 
/*  given  goal,  that  rule  is  added  to  the  front  of  the  "why"  */ 
/*  trace.  */ 

/*  */ 
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/* — . - . . */ 

solve ( n .Trace, Trace) . 

solve ([Goal | Others] , Trace, NewTrace) 

retractall(why_trace(_)) ,  /*  Initialize  the  "why"  */ 

asserta(why_trace( [goal :: Goal])) ,  /*  trace.  */ 

is_known(Goal .Trace .Tracel) , 

(  conf irmed(Goal) , !  /*  Write  each  triple  as  */ 

;  /*  it’s  solved,  but  don’t  */ 

nl ,write_triple(Goal) ,nl  ),  /*  write  a  triple  that's  */ 

solve(Others .Tracel .NewTrace) .  /*  been  told  explicitly  */ 

/*  by  the  user.  */ 

write_triple( [Obj .Attr.Val] ) 

writelistC [Obj , ’  ’.Attr,’  * ,Val,’.’]). 

/* . IS. KNOWN . */ 

/*  */ 

/*  The  ’is.known’  procedure  maintains  a  trace  of  the  path  of  */ 
/*  the  solution-tree  leading  to  the  triple  currently  under  */ 
/*  consideration.  ’ is_known(Triple, Trace, NewTrace) ’  means  */ 
/*  that  if  reasoning  to  a  certain  point  has  been  recorded  in  */ 
/*  the  list  ’Trace’,  then  the  additional  triple  ’Triple’  is  */ 
/*  known  via  reasoning  recorded  by  the  list  ’NewTrace’.  */ 

/+  */ 

/* . */ 

/+  A  triple  is  not  known  if  it  has  been  denied  by  the  user.  */ 

is_known(Triple, Trace, Trace) 
denied(Triple) , 

i 

•  > 

fail. 

/*  A  triple  is  known  if  it  is  already  logged  in  the  trace.  */ 

is_known( [0,A,V] .Trace, [in.trace: : [Tag, [0,A,V]] |Trace] ) 
member(Tag: : [0,A,V] .Trace) , 

Tag  \==  confirmed.not, 

/*  A  triple  is  known  if  it  has  been  confirmed  by  the  user.  */ 
is_known(Triple, Trace, [was.told: :Triple iTrace] ) 
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conf irmed(Triple) . 


/*  A  triple  is  known  if  it  is  a  fact  in  the  rule-base.  */ 

is.known (Triple, Trace, [fact : :Triple (Trace] )  :- 
fact::  Triple. 

/*  A  triple  [X,P,Y]  is  known  if  the  Prolog  goal  P(X,Y)  sue-  */ 
/*  ceeds,  either  because  P  is  a  built-in  predicate,  or  because  */ 
/*  the  rule-base  has  prolog-code  defining  P.  The  triple  */ 

/*  [2,member, [1 ,2]] ,  for  example,  is  converted  into  the  goal  */ 
/*  member (2, [1 ,2] ) ,  which  is  then  executed  by  Prolog.  To  keep  */ 
/*  non-Prolog-programmers  out  of  trouble,  the  triple  [X,is,Y]  */ 
/*  is  trapped  so  that  it  will  not  be  executed  as  an  arithmetic  */ 
/*  statement.  The  triple  [X,:=,Y]  is  interpreted  as  Prolog’s  */ 
/*  arithmetic  or  assignment  goal,  X  is  Y.  */ 

/*  */ 
/*  This  kind  of  triple,  which  runs  off  and  does  a  computation,  */ 
/*  is  called  a  "procedural  attachment",  or  "demon."  */ 

is_known( [Obj ,Attr,Val] .Trace, [solved: : [Obj ,Attr,Val] |Trace])  :- 
atom(Attr) ,  /*  Attr  must  be  a  legal  functor.  */ 

( 

Attr  ==  :=,  ! , 

Obj  is  Val  /*  Interpret  ’:  =  ’  as  Prolog’s  ’is’.  */ 

» 

not  (check_reserved_words(Attr)) , 

/*  Interpret  everything  else,  except  */ 

T  =..  [Attr ,0b j , Val] ,/*  reserved  words  for  rule-base,  as  a  */ 
/*  functor  on  a  two-place  */ 

T,  !  /*  predicate  to  be  solved  as  a  goal.  */ 

). 

/*  A  triple  is  known  if  it  is  the  head  of  a  rule  and  the  con-  */ 
/*  ditions  of  the  rule  are  satisfied.  We  put  a  rule  that  we  */ 
/*  encounter  at  the  head  of  the  "why"  trace,  erasing  any  du-  */ 
/*  plicates  of  the  rule  that  are  already  in  the  "why"  trace.  */ 
/*  The  "why"  trace  is  maintained  in  the  database,  in  a  clause  */ 
/*  of  the  form  ’why_trace(<List  of  goals  and  rules>) ’ .  This  */ 
/*  differs  from  the  "how"  trace,  which  is  handed  as  an  argu-  */ 
/*  ment  from  goal  to  goal.  */ 

is .known (Triple, Trace, [was.proved: : [Triple, Rule] | Trace] )  :- 
member(Rule: :  Triple  derived.from  .Conds .Trace) , 


F-77 


is_known(Trpl ,Trc, [Rule: :  Trpl  derived.from  Conds (Trcl] ) 
Rule : :  if  Conds  then  Trpl , 

(  verbose, 

writelist([’ Trying  ’,  Rule,  ’::  ’ ,  Trpl]),nl 

9 

not  verbose) , 
why_trace(WhyTrace) , 

remove(Rule: :  Trpl  derived.from  Conds .WhyTrace .PartWhy) , 
append ( [Rule: :  Trpl  derived.from  Conds] .PartWhy .NewWhy) , 
retract (why_trace(_)) , 
asserta(why_trace (NewWhy) )  , 
is_known(Conds,Trc,Trcl) , 

(  verbose, 

writelistC [’Proved  ’,  Rule,  Trpl]),nl 

I 

not  verbose  ) , 


/*  A  condition  involving  "and",  "or",  or  "not"  is  known  if  its  */ 
/*  parts  are  known  in  suitable  combinations.  */ 

is.known (Triples  1  and  Triples2, Trace, Trace2) 
is_known(Triplesl .Trace, Tracel) , 
is_known(Triples2 .Tracel ,Trace2) . 

is_known(Triplesl  or  _Triples2, Trace, Tracel) 
is_known (Triples  1 .Trace, Tracel) . 
is_known(_Triplesl  or  Triples2, Trace, Trace2) 
is_known(Triples2, Trace, Trace2) . 

is_known(not  Triple, Trace, [conf irmed.not: : Triple  I  Trace]) 
not  is_known(Triple,Trace,_Tracel) . 


/*  A  triple  is  known  if  (a)  the  rule-base  classifies  it  as  */ 
/*  "askable"  and  if  (b)  the  user  confirms  it.  The  user  may  */ 
/*  request  a  "why"  explanation  before  responding  to  the  ques-  */ 
/*  tion.  */ 


is_known([0,A,V] .Trace, [was.told: : [0,A,V] (Trace]) 

askable::  [0,A,_],  /*  ’ask_about’  causes  the  side-effect  */ 

ask_about( [0,A,V] ) ,  /*  of  confirming  or  denying  [0,A,V]  in  */ 

! ,  /*  working  memory.  The  clause  succeeds  */ 

confirmed([0,A,V] ) .  /*  if  the  triple  was  confirmed.  */ 
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/* . - . - . ASK.ABOUT - - - -*/ 

/*  If  the  user  is  asked  about  a  triple  [D,A,V]  in  which  V  is  */ 
/*  a  variable,  we  assume  that  only  one  value  of  V  is  allowed  */ 
/*  for  that  triple.  The  askable-fact  in  the  rule-base  is  to  */ 
/*  have  the  form  'askable: : [0, A, LegalVals] ' .where  LegalVals  is  */ 
/*  either  a  string  describing  legal  values  or  a  list  enumer-  */ 
/*  ating  such  values.  When  the  user  supplies  a  legal  value  for  */ 
/*  V,  the  triple  is  confirmed  in  working  memory.  */ 

ask_about( [Obj ,Attr,Val] )  :- 
var(Val) , 

•  > 

not  conf irmed([0bj ,Attr,_] ) , 
nl,  writelist( [Obj , ’  ’,Attr,’?  ’]),nl, 
askable: :  [Obj ,Attr .LegalValues] , 
write(’Legal  values:  ’),  write(LegalValues) ,  nl, 
write(’>  ’),  read(Reply), 

(  /*  If  the  user  replies  'why.',  give  him  an  explanation  and  */ 
/*  ask  again  for  a  value.  */ 

( 

means (Reply, why) , 
explain_why( [Obj ,Attr ,Val] ) , 

i 

•  » 

ask_about( [Obj ,Attr ,Val] ) 

) 

* 

/*  If  LegalValues  is  a  list,  check  that  the  reply  is  in  */ 
/*  the  list.  */ 

( 

atom(LegalValues)  /*  LegalValues  is  a  string.*/ 

> 

LegalValues  =  [_ I _] ,  /*  LegalValues  is  a  list.  */ 

member (Reply .LegalValues) 

). 

i 

*  » 

assertz (conf irmed ( [Obj , Attr , Reply] ) ) 

I 

write( 'Please  re-enter  your  reply. ’),nl, 
ask_about( [Obj ,Attr,Val]) 

). 

/*  If  we  get  to  this  clause,  the  user  is  being  asked  to  reply  */ 
/*  yes  or  no  concerning  a  triple  [0,A,V]  in  which  V  is  not  a  */ 


/*  variable.  For  given  0  and  V,  working  memory  may  store  more  *f 
/*  than  one  triple,  confirmed  or  denied,  having  different  val-  */ 
/*  ues  of  V.  */ 

ask_about( [Obj ,Attr,Val] ) 

not  confirmed( [Obj , Attr , Val] ) , 
not  denied( [Obj , Attr , Val]  ) , 
nl, 

writelist( [Obj , ’  * ,Attr,’  ’,Val,’?  (yes. /no. /why.) ’]) , 
nl,write(’>  ’ ) .read(Reply) , 

( 

means(Reply ,yes) , 

assertz(conf  irmed(  [Obj  ,Attr  ,Val] )) ,  ! 

» 

means (Reply , no) , 

assertz(denied( [Obj .Attr.Ve*])) ,  ! 

» 

means (Reply , why) , 
explain.why ( [Obj , Attr ,Val] ) , 

i 

•  » 

ask_about( [Obj , Attr , Val] ) 

t 

write ('Please  re-enter  your  reply.’ ),nl, 
ask_about( [Obj , Attr , Val] ) 

)• 

/*— . . ASK  ABOUT  VERBOSE - - */ 

ask_about_verbose 
retractall (verbose) , 

write(’  Question:  Do  you  want  verbose  operation(y . /n. )?  ’), 

i 

•  » 

read(Reply) ,nl ,nl , 
means (Reply , yes) , 
assert (verbose) . 


/*- . ASK  ABOUT  CHECKING  TYPE  — . */ 

ask_about_checking_type 
writeO  Question: 

Do  you  wish  to  check  ACTIVITY  BOX,  BOUNDARY  ARROWS  »),nl, 
write(’  or  to  have  HELP  MESSAGES  ?’),nl,nl, 

write('  To  check  ACTIVITY  BOX  ->  Enter  a.’),nl, 

write( ’  To  check  BOUNDARY  ARROWS  ->  Enter  b.’),nl, 

write(’  To  have  HELP  MESSAGE  ->  Enter  h.’),nl, 
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write( ’Choice  :  ’), 
read(Reply) ,nl , 

(  (  Reply  ==  a, 

load_sarule( ’ ACTIVITYSARULE. PRO ’ ) , 
load_working_memory( ’CHECKBOX .PRO ’ ) , 

!  ) 

* 

(  Reply  ==  b, 

load.sarule ( ’ BOUNDARYSARULE . PRO ’ ) , 
load.w orking.memory ( ’ CHECKBOUNDARY . PRO ’ ) , 

!  ) 

> 

(  Reply  ==  h, 
help.messages , 

I 

•  • 

ask_about_checking_type  ) 

» 

(  write(’  Please  re-enter  your  choice !!!!’) ,nl ,nl , 
ask_about_checking_type  ) 

)- 

/*- . . ASK  ABOUT  TRACE . - . — . — */ 

ask_about_trace(Trace) 
nl ,nl , 

write(’  Question:  Do  you  wish  to  see  how  this  answer  ’),  nl, 
write (’  was  arrived  at(y./n.)?  ’), 

read(Reply)  , 

(  means (Reply , yes) ,  !, 
write.trace (Trace) 

I 

true  ) . 


/* . . -  ASK  ABOUT  SAVING  WORKING  MEMORY - */ 

ask_about_saving_working_memory  nl, 

write ( ’ /*****************! ! !  WORNING  ! ! ! ************************/ ’ )  ,nl , 
write(’/*  After  this  session,  all  working  memory  elements  will  */’),nl, 
write(’/*  be  erased  except  for  elements  being  protected  by  */’),nl, 
writeO/*  keep  statements  in  the  knowledge  base.  */’),nl, 

write ( * /********************************************************/ ’ ) ,nl , 
nl, 

write(’  Question:  Do  you  wish  to  save  the  current  working  memory’), nl, 
write(’in  a  file(y./n.)?  ’), 
read(Reply) ,nl , 
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(  means (Reply , yes) , 
save.working.memory , 
erase. working.memory ,  ! 

9 

erase.working.memory  ) . 


/* . EXPLAIN.WHY . . */ 

explain.vhy (Triple) 
why.trace (WhyTrace) , 
write( ’Because: : ’) ,nl, 
justify (Triple, WhyTrace) . 

justify(Triple,WhyTrace) 
member (goal : : Goal , WhyTr ace) , 

Triple  =  Goal, 

writelist([’This  will  satisfy  the  goal  ’,Goal]),nl, 
nl, 

I 

justify(Triple.WhyTrace) 
member (Rule :: Head  derived.from  Cs .WhyTrace) , 

(  among (Tr iple, Cs ) , 
writelist([’I  can  use  * .Triple] ) ,nl 

9 

among (not  Triple, Cs), 

writelist([’I  can  use  NOT  ’ .Triple] ) ,nl 

), 

remove (Rule :: Head  derived.from  Cs .WhyTrace .NewTrace) , 
list.known.triples(Cs) , 

writelist([’  to  help  satisfy  ’.Rule,'::  ’ .Head] ) ,nl ,nl , 
justify (Head, NewTrace) . 

list.known.triples(Cs)  :- 
among(Triple.Cs) , 

( 

confirmed (Triple) 

9 

fact::  Triple 

), 

writelist([*  knowing  ’ .Triple] ) ,nl , 
fail. 

list _known.tr iples(_) . 

among(Triple, Conditions)  :- 
Triple  *  Conditions. 
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among(Triple,  FirstTriple  and  OtherConditions)  :- 
Triple  =  FirstTriple 
* 

among(Triple, OtherConditions) . 
among (Triple,  FirstTriple  or  OtherConditions) 

Triple  =  FirstTriple 
* 

among(Triple, OtherConditions) . 

why  /*  Diagnostic  utilities  for 

why.trace (Trace) ,  /*  the  why-trace. 

write.trace(Trace) . 

list.why 

why.trace (Trace) , 
member (M, Trace) , 
write(M) ,nl,nl, 
fail. 

why.candidates 
why.trace (Trace) , 

member(_Rule: :  Head  derived.from  Cs, Trace), 
among (Triple.Cs) , 

write(’Head  =  ’ ) .write(Head) ,nl , 
write( ’Triple  =  ’ ) .write(Triple) ,nl ,nl , 
fail. 


/* . - . WRITE.TRACE . — 

write_trace( []  ) 
nl . 

write_trace( [Tag: : [0,A,V] |Rest]) 

(  Tag  *=  goal,  ! ,  write( ’GOAL: :  ’) 

t 

Tag  *=  fact,  !,  write ( 'FACT: :  ’) 

I 

Tag  as  solved,  !,  write ( ’SOLVED: :  ’) 

» 

Tag  ==  was .told,  ! ,  write ( ’TOLD: :  ’) 

t 

Tag  a=  conf irmed.not ,  !,  write ( ’CONTRADICTED: :  ’) 

). 

write([0,A,V]) ,nl, 
write.trace(Rest) . 
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write_trace( [in.tr ace: : [Tag, Triple] |Rest]) 

i 

•  i 

write( ’KNOWN: :  ’) .write(Tag) ,write(* : :  ’ ) .write(Triple) ,nl , 

write_trace(Rest) . 

write_trace( [was.proved: : [Triple, Rule] |Rest] )  !, 

write( ’PROVED : :  ’) .write(Triple) ,write(’  using  ’) .write(Rule) ,nl, 
write_trace(Rest) . 

write_trace([Rule: :  Triple  derived.from  Conditions  I  Rest] )  !, 

writelist([Rule, * : :  ’.Triple,’  Was  Derived  From’]),nl, 
write_conditions (Conditions) , 
write_trace(Rest) . 
write_trace( [X |Rest] )  : - 
write(X) ,nl, 
write_trace(Rest) . 

write_conditions([X,Y,Z]) 
tab(8) ,write( [X,Y,Z] ) ,nl. 
write_conditions(not  [X,Y,Z])  : - 

tab (4) , write ( 'NOT  ’ ) .write ( [X,Y,Z] ) ,nl . 
write_conditions( [X,Y,Z]  and  Conditions)  !, 
tab(8) , write ([X.Y.Z] ) , write (’  AND’) ,nl, 
write_conditions (Conditions) . 
write_conditions(not  [X.Y.Z]  and  Conditions)  !, 

t  ib(4) ,write(’N0T  ’ ) ,write( [X ,Y,Z] ) ,write( ’  AND’),nl, 
write.conditions (Conditions) . 
write.conditions (Conditions  1  and  Conditions2) 

write_conditions(Conditionsl) ,tab(8) ,write( ’ AND’ ) ,nl , 
write_conditions(Conditions2) . 
write_conditions( [X,Y,Z]  or  Conditions)  !, 
tab (8) , write ( [X.Y.Z] ) , write ( ’  OR’ ) ,nl , 
write.conditions (Conditions) . 
write_conditions(Conditionsl  or  Conditions2) 

write_conditions(Conditionsl) ,tab(8) .write('OR') ,nl, 
write_conditions(Conditions2) . 
write_conditions(not  [X.Y.Z]  or  Conditions) 

tab(4) ,write(’N0T  ’ ) ,write( [X ,Y ,Z] ) ,write( '  0R’),nl, 
write.conditions (Conditions) . 


/* . FILE  I/O . *1 

get_f ilename (Filename) 

write( ’Please  supply  a  filename:  ’), 
read(Filename) . 
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load.sarule(SAruleType) 
retractall (_ : r  _) , 
see(SAruleType) , 
load.f ile, 
seen. 

load.f ile 
read(Term) , 
load(Term) . 

load(end_of _f ile)  !. 

load (Term) 

assertz(Term) , 
load.f ile. 

load.working.memory(CheckFileType) 
retractall (conf irmed(_) ) , 
retractall(denied(_))  , 
see(CheckFileType) , 
load.f ile, 
seen. 

save.working.memory 

get.f ilename (Filename) , 
tell (Filename) , 
save.wme, 
told. 

save.wme  : - 

conf irmed(Triple) , 
writeq(conf irmed(Triple)) , 
write(’ . ') ,nl, 
fail. 

save.wme  : - 

denied (Triple) , 
writeq(denied(Triple)) , 
write(’ . ’) ,nl, 
fail. 

save.wme. 

/* . UTILITY  PROCEDURES . */ 

check.reserved.words(Attr) 
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member(Attr, [’  * ,is,input_is,has_input_number,output_is, 
has.output .number .control. is, has.control.number, 
mechanism.is ,has_mechanism_number .number.is , 
should.be .has .number] ) . 

show.head.message  : - 
nl.nl, 

write ( *  /***************  IDEFO  Syntax  Messages  ***************/’), 

nl. 

help .messages 

reconsult ( ' HELP . PRO ' ) . 

not(Predicate) 

call (Predicate) ,  !,  fail. 
not(_) . 

writelist(  □ )  . 
writelistC [X |L] ) 
write(X) , 
writelist(L) . 

member (X, [Xl_]) . 
member (X, [_ | L] ) 
member (X.L) . 

append(  [] ,L,L) . 
append([X|L] ,M, [X|N]) 
append(L.M.N) . 

remove (_,  [],□)• 
removeCX, [XlL] ,M) 

i 

•  9 

remove(X, L.M) . 
removeCX, [Y I L] , [Y | M] ) 
remove(X, L.M) . 

prefix ( □  ,  □)  • 

prefix( [Goal  I  Goals] , [goal: :Goal|PrefixedGoals] ) 
pref ix(Goals ,Pref ixedGoals) . 

li8t_working.memory 
conf irmed(Triple) , 

write (confirmed(Triple)) ,write(* . ’) ,nl, 
fail. 


list.working.memory 
denied(Triple) , 
write(denied(Triple)) , 
write(’ . ’ ) ,nl, 
fail. 

list_working_memory . 

means (Reply , yes) 

member (Reply , [y,yes]) . 
means (Reply , no) 

member (Reply , [n , no]  ) . 
means (Reply, why) 

member (Reply , [why , w] ) . 

start .message 

VTite(‘ /********************************************************/ ’ ) ,nl , 


write ( ’/*  */’),nl, 
write( ’ /*  WELCOME  TO  IDEFO  SYNTAX  EXPERT  SYSTEMS  */'),nl, 
write(’/*  */’) ,nl, 
write(’/*  I. Type  start,  to  begin  a  new  session.  */’),nl, 
write(’/*  */’),nl, 
write(’/*  II.  Answer  all  questions  using  lower  case.ending  with*/’),nl, 
write(’/*  a  period.  */’),nl, 
write(’/* 

write('/*  III.  Type  halt.  to  exit  prolog  session.  */’),nl, 
write(’/*  */’) ,nl, 


write ( ’ /********************************************************/ ' ) ,nl , 
nl. 


?-  start .message. 
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Activity  IDEFq  Syntax  Rules 

/******************************************************************* 


*  * 

*  DATE:  25  Apr.  1990  * 

*  VERSION:  1.0  * 

*  NAME:  ACTIVITYSARULE . PRO  * 

*  TITLE:  Rule  base  for  an  activity  box  * 

*  COORDINATOR:  Intaek  Kim  * 

*  PROJECT:  Knowledge  base  * 

*  OPERATING  SYSTEM:  UNIX  4.3  * 

*  LANGUAGE:  Quintus  Prolog  * 

*  FILE  PROCESSING:  This  module  should  be  used  with  an  inference  * 

*  engine,  BC3.  * 

*  CONTENTS:  Rules  for  checking  IDEFO  syntax  of  an  activity  box.  * 

*  HISTORY:  * 


******************************************************************* 

/*********************  GOALS  **************************/ 

/*  These  lists  of  goal  present  the  resulting  message.  */ 

goals::  [[’Name’,  ’  _Name] ,  /*  Goal  for  NAME  of  the  box  */ 

[’Input’,  ’  ’,  .Input],  /*  Goal  for  INPUT  of  box  */ 

[’Output’,  ’  ’,  .Output],  /*  Goal  for  OUTPUT  of  box  */ 

[’Control’,  ’  ’,  .Control],/*  Goal  for  CONTROL  of  box  */ 

[’Mechanism’,  ’  ’,  .Mechanism],  /*  Goal  for  MECHANISM  */ 

[’Number’,  ’  ’,  .Number]] .  /*  Goal  for  the  box  NUMBER  */ 

/**********************  RULES  ******************************/ 
/****************  About  Activity  Name  **********************/ 
rulel  ::  if  [activityname,  is,  ’ ’] 
then  [’Name’,  ’  ’,  ’  -->  ERROR:  No  Activity  Name. 

Each  box  must  have  an  activity  name’]. 

rule2  ::  if  [activityname,  is,  Activity] 
and  [Activity,  \*=,  ”] 

then  [’Name’,  ’  ’,  ’  -->  CORRECT:  Activity  Name  is  OK’]. 

/********************  About  Input  **************************/ 
rule3  ::  if  [activityname,  is,  Activity] 
and  [Activity,  input.is,  null] 
then  ['Input',  ’  ',  CORRECT:  No  Input  Arrows,  however, 

Input  is  OK’] . 

rule4  ::  if  [activityname,  is,  Activity] 


F-88 


and  [Activity,  input.is,  *’] 
then  [’Input*,  ’  *,  *  -->  ERROR:  No  Input  Label 

Each  Input  arrow  must  have  an  input  label’]. 

rule5  ::  if  [activityname,  is,  Activity] 

and  [Activity,  has _ input. number,  InputNumber] 
and  [InputNumber,  >,  5] 
then  [’Input’,  ’  ’,  ’  ~ >  RECOMMEND: 

You  would  better  reduce  the  number  of  Input  arrows 
from  0  to  5’]  . 

rule6  ::  if  [activityname,  is,  .Activity] 

then  [’Input’,  ’  ’,  ’  — >  CORRECT:  Input  is  OK’]. 

/********************  About  Output  ***********************/ 

I*  If  there  is  a  box  and  the  output  of  the  box  is  empty,  */ 

/*  then  there  is  no  output/name.  */ 

rule7  ::  if  [activityname,  is.  Activity] 

and  [Activity,  output. is,  null] 
then  [’Output*,  ’  ’,  *  — >  ERROR:  You  should  have  at  least 

one  output  arrow’] . 

rule8  ::  if  [activityname,  is.  Activity] 
and  [Activity,  output.is,  ”] 
then  [’Output*,  *  ’,  ’  — >  ERROR:  No  Output  Label. 

Each  Output  Arrow  should  have  an  output  Label’]. 

rule9  ::  if  [activityname,  is,  Activity] 

and  [Activity,  has.output.number,  OutputNumber] 
and  [OutputNumber,  >,  5] 

then  [’Output*,  ’  *,  ’  — >  RECOMMEND: 

You  would  better  reduce  the  number  of  Output  arrows 
from  1  to  5’] . 

rulelO  ::  if  [activityname,  is,  .Activity] 

then  [’Output’,  *  ’,  ’  — >  CORRECT:  Output  is  OK’]. 

/*******************  About  Control  *******************/ 
rulell  ::  if  [activityname,  is,  Activity] 

and  [Activity,  control.is,  null] 
then  [’Control’,  ’  ’,  ’  — >  ERROR:  You  should  have  at  least 

one  control  arrow’] . 

rule!2  ::  if  [activityname,  is,  Activity] 
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and  [Activity,  control.is,  ’ ’] 
then  [’Control’,  ’  ’,  ’  — >  ERROR:  No  Control  Label. 

Each  Control  Arrow  should  have  a  control  Label’]. 

rulel3  ::  if  [activityname,  is,  Activity] 

and  [Activity,  has.control.number ,  ControlNumber] 
and  [ControlNumber,  >,  5] 

then  [’Control’,  »  »,  »  — >  RECOMMEND: 

You  would  better  reduce  the  number  of  Control  arrows 
from  1  to  5’] . 

rulel4  ::  if  [activityname,  is,  .Activity] 

then  [’Control’,  ’  ’,  *  — >  CORRECT:  Control  is  OK’]. 

/*******************  About  Mechanism  ******************/ 
rulel5  ::  if  [activityname,  is,  Activity] 

and  [Activity,  mechanism.is,  *’] 
then  [’Mechanism’,  ’  ’,  * — >  ERROR:  No  Mechanism  Label. 

Each  Mechanism  Arrow  should  have  a  mechanism  Label’] . 

rulel6  ::  if  [activityname,  is.  Activity] 

and  [Activity,  mechanism.is,  null] 
then  [’Mechanism’,  ’  ’,  ’ — >  CORRECT:  No  Mechanism  Arrows,  however, 
Mechanism  is  OK’]. 

rulel7  ::  if  [activityname,  is.  Activity] 

and  [Activity,  has.mechanism.number ,  MechanismNumber] 
and  [MechanismNumber,  >,  5] 
then  [’Mechanism*,  ’  ’,  ’ — >  RECOMMEND: 

You  would  better  reduce  the  number  of  Mechanism  arrows 
within  0  to  S’] . 


rulel8  ::  if  [activityname,  is,  .Activity] 

then  [’Mechanism’,  ’  ’,  CORRECT:  Mechanism  is  OK’]. 

/***********************  Activity  Number  **********************/ 

/*  If  there  is  a  box  and  the  number  of  the  box  is  0,  that  is,  */ 

/*  the  box  has  no  number,  the  box  must  be  the  top  most  box.  */ 

rulelS  ::  if  [title,  is,  Activity] 

and  [Activity,  number.is,  Number] 
and  [Number,  ■*,  0] 

then  [’Number’,  ’  ’,  ’ — >  CORRECT:  Activity  number  is  OK. 
This  activity  must  be  the  top  most  level  box*]. 
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rule20  ::  if  [title,  is,  Activity] 

and  [Activity,  number.is,  Number] 
and  [Number,  \== ,  0] 

then  [’Number’,  *  ’,  ’ — >  ERROR:  This  activity  must  be 
the  top  most  level  box. 

This  activity  don’’t  need  a  box  number’]. 

/*  Each  activity  box  must  have  a  number  for  the  box  within  */ 

/*  1  through  6  except  for  the  top  most  level  activity  box.  */ 

/*  If  there  is  a  box  and  the  number  of  the  box  is  0,  then  */ 

/*  there  is  no  number  in  the  box.  */ 

rule21  ::  if  [Activity,  number.is,  Number] 

and  [title,  is,  ParentActivity] 
and  [ParentActivity,  \==,  Activity] 
and  [Number,  == ,  0] 

then  [’Number’,  ’  ’,  ’ — >  ERROR:  Activity  box  has  no  number. 
The  activity  box  should  have  a  box  number  from  1  to  6. 

(If  the  activity  box  is  the  top  most  level  one,  then 
ignore  this  message)’]. 

rule22  ::  if  [Activity,  number.is,  .Number] 
and  [title,  is,  ParentActivity] 
and  [Parent Activity,  \==,  Activity] 
and  [activity.number,  is,  in.legal.range] 

then  [’Number’,  ’  ’,  ' — >  CORRECT:  Activity  box  number 

is  OK.’]. 

rule23  ::  if  [Activity,  number.is,  .Number] 
and  [title,  is,  ParentActivity] 
and  [ParentActivity,  \==,  Activity] 
and  [activity.number ,  is,  in.illegal.range] 

then  [’Number’ ,  ’  ’,  '  — >  ERROR:  Activity  box  number  is 

not  proper. 

The  recommended  range  of  number  is  1  to  6’]. 

/*  These  rules  are  the  second  level  rules.  */ 

rule24  ::  if  [.Activity,  number.is,  Number] 
and  [Number,  >,  0] 

and  [Number,  <,  7] 

then  [activity.number,  is,  in.legal.range]. 

rule25  ::  if  [.Activity,  number.is,  Number] 
and  [Number,  <,  0] 
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then  [activity .number,  is,  in.illegal.range] 

rule26  ::  if  [.Activity,  number.is,  Number] 
and  [Number,  >,  6] 

then  [activity.number ,  is,  in.illegal.range] 
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Boundary  IDEF0  Syntax  Rules 


/ ******************************************************************** 


*  * 

*  DATE:  25  Apr.  1990  * 

*  VERSION:  1.0  * 

*  FILE  NAME:  BOUND ARYSARULE . PRO  * 

*  TITLE:  Rule  base  for  boundary  arrows  * 

*  COORDINATOR:  Intaek  Kim  * 

*  PROJECT:  Knowledge  base  * 

*  OPERATING  SYSTEM:  UNIX  4.3  * 

*  LANGUAGE:  Quintus  Prolog  * 

*  FILE  PROCESSING:  This  module  should  be  used  an  inference  engine  * 

*  BC3 .  * 

*  CONTENTS:  Rules  for  checking  IDEFO  syntax  of  boundary  arrows.  * 

*  HISTORY:  * 


******************************************************************** 
/*********************  goals  **************************/ 

/*  These  lists  of  goal  present  the  resulting  message.  */ 

goals::  [[’Boundary  Input’,  ’  ’,  .Input], 

/*  Goal  for  boundary  input  in  any  IDEFO  diagram  */ 

[’Boundary  Output’,  ’  ’,  .Output], 

/*  Goal  for  boundary  output  in  any  IDEFO  diagram  */ 

[’Boundary  Control’ ,  ’  ’,  .Control], 

/*  Goal  for  boundary  control  in  any  IDEFO  diagram  */ 

[’Boundary  Mechanism’ ,  ’  ’,  .Mechanism] 

/*  Goal  for  boundary  mechanism  in  any  IDEFO  diagram  */ 

]. 

/**********************  RULES  **********************/ 

/****  When  there  is  no  information  of  parent  box  ***/ 
rulel  ::  if  [child.title,  is,  ParentBox] 

and  not  [activityname ,  is,  ParentBox] 
then  [boundarysarule,  is,  stalled]. 

rule2  ::  if  [boundarysarule,  is,  stalled] 
then  [’Boundary  Input’,  ’  ’,  ’ 

— >  ! ! !  THIS  IS  A  FATAL  ERROR  !!!’]. 

rule3  ::  if  [boundarysarule,  is,  stalled] 
then  [’Boundary  Output’,  ’  ’,  ’ 

-->  There  is  nothing  about  Parent  activity’]. 

rule4  ::  if  [boundarysarule,  is,  stalled] 
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then  [’Boundary  Control’,  ’  ’,  ’ 

— >  Maybe  you  have  tried  to  check  syntax  with 

a  file  without  PARENT  ACTIVITY  BOX  information’] . 

ruleS  ::  if  [boundarysarule,  is,  stalled] 

then  ['Boundary  Mechanism',  ’  ’ 

— >  PLEASE  START  AGAIN  !!!’]. 

/*******************  About  Boundary  Input  ******************/ 

/*  No  label  on  boundary  input  arrow  */ 
rule6  ::  if  [boundary.input ,  is,  ’ ’] 

then  [’Boundary  Input’,  ’  ',’ 

— >  ERROR:  No  boundary  input  label’]. 

/*  No  label  on  input  arrow  of  the  parent  box  */ 
rule7  ::  if  [child.title ,  is,  ParentBox] 
and  [ParentBox,  input.is,  "] 
then  [’Boundary  Input’,’  ’,’ 

— >  ERROR:  Parent  Input  has  no  label’]. 

I*  The  number  of  Input  arrow(s)  of  the  Parent  Activity  */ 

/*  box  is  differ  from  that  of  the  Boundary  Input  arrow(s).*/ 

/*  The  number  of  the  Parent  Input  arrow(s)  >  The  number  */ 

/*  of  the  Boundary  Input  arrow(s).  */ 

rule8  ::  if  [child_title,  is,  ParentBox] 

and  [ParentBox,  has_input_number ,  InputNumber] 
and  [boundary. input ,  has.number,  BoundlnNumber] 
and  [InputNumber,  >,  BoundlnNumber] 
then  [’Boundary  Input’,’  ’,’ 

— >  ERROR:  The  number  of  Input  arrow (s)  of 

Parent  Activity  box  is  greater  than  that  of 
Boundary  Input  arrow(s)  —  Must  have  the  same  number’]. 

/*  The  number  of  Input  arrow(s)  of  the  Parent  Activity  box  is  */ 
/*  differ  from  that  of  the  Boundary  Input  arrow(s).  */ 

/*  The  number  of  the  Parent  Input  arrow(s)  <  The  number  of  the  */ 
/*  Boundary  Input  arrow(s).  */ 

rule9  ::  if  [child.title,  is,  ParentBox] 

and  [ParentBox,  has.input.number ,  InputNumber] 
and  [boundary. input ,  has.number,  BoundlnNumber] 
and  [InputNumber,  <,  BoundlnNumber] 
then  [’Boundary  Input’,’  ’,’ 

— >  ERROR:  The  number  of  Input  arrow (s)  of 

Parent  Activity  box  is  less  than  that  of 
Boundary  Input  arrow(s)  —  Must  have  the  same  number’] . 
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/*  If  the  number  of  arrows  is  greater  than  I've,  recomend  */ 

/*  about  how  many  the  number  of  arrows  exists.  */ 

rulelO  ::  if  [boundary _ input ,  has.number,  BoundlnNumber] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  has_input_number ,  BoundlnNumber] 
and  [BoundlnNumber,  >,  5] 
then  [’Boundary  Input’,  ’  ’,  ’  — >  RECOMMEND: 

You  would  better  reduce  the  number  of  arrows  to  six 
below ’] . 

/*  No  boundary  Input  arrow  and  No  Input  at  Parent  Box  */ 

rulell  ::  if  [child.title,  is,  ParentBox] 
and  [boundary _ input ,  is,  null] 
and  [ParentBox,  input.is,  null] 
then  [’Boundary  Input’,  ’  ’,’ 

— >  CORRECT:  Boundary  Input  is  OK’]. 

/*  Consider  the  correct  case  acording  to  the  Number  of  */ 

/*  Input  arrow(s).  */ 

rulel2  ::  if  [boundary. input ,  has.number,  BoundlnNumber] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  has.input.number,  BoundlnNumber] 
then  [case.of.boundary.in,  is,  BoundlnNumber]. 

/*  Case  1:  The  number  of  Boundary  Input  arrow  is  1.  */ 

rulel3  ::  if  [case.of.boundary.in,  is,  1] 

and  [child.title,  is,  ParentBox] 
and  [ParentBox,  input.is,  Parentlnput] 
and  [boundary _ input  1 ,  is,  Parentlnput] 
then  [’Boundary  Input’,  ’  *,’ 

— >  CORRECT:  Boundary  Input  is  OK’]. 

/*  Case  2:  The  number  of  Boundary  Input  arrows  is  2.  */ 

rulel4  ::  if  [case.of.boundary.in,  is,  2] 

and  [boundary. input  1 ,  is,  Parentlnputl] 
and  [boundary _input2,  is,  Parentlnput2] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  input.is,  Parentlnputl] 
and  [ParentBox,  input.is,  Parentlnput2] 
then  [’Boundary  Input’,  ’  ’,’ 

— >  CORRECT:  Boundary  Input  is  OK’]. 

/*  Case  3:  The  number  of  Boundary  Input  arrows  is  3.  */ 

rulel5  ::  if  [case.of.boundary.in,  is,  3] 
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and  [boundary _ input 1 ,  is,  Parentlnputl] 
and  [boundary. input2,  is,  Parentlnput2] 
and  [boundary .input 3,  is,  Parentlnput3] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  input.is,  Parentlnputl] 
and  [ParentBox,  input.is,  Parentlnput2] 
and  [ParentBox,  input.is,  Parentlnput3] 
then  [’Boundary  Input’,  ’  ’,* 

— >  CORRECT:  Boundary  Input  is  OK’]. 

/*  Case  4:  The  number  of  Boundary  Input  arrows  is  4.  */ 

rulel6  ::  if  [case.of .boundary.in,  is,  4] 

and  [boundary. input  1 ,  is,  Parentlnputl] 
and  [boundary_input2,  is,  Parentlnput2] 
and  [boundary_input3,  is,  Parentlnput3] 
and  [boundary _input4,  is,  Parentlnput4] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  input.is,  Parentlnputl] 
and  [ParentBox,  input.is,  Parentlnput2] 
and  [ParentBox,  input.is,  Parentlnput3] 
and  [ParentBox,  input.is.  Parent Input 4] 
then  [’Boundary  Input’,  ’  ’,’ 

— >  CORRECT:  Boundary  Input  is  OK’]. 

/*  Case  5:  The  number  of  Boundary  Input  arrows  is  5.  */ 

rulel7  ::  if  [case.of .boundary.in,  is,  5] 

and  [boundary. input  1 ,  is,  Parentlnputl] 
and  [boundary. input2,  is,  Parent Input2] 
and  [bound ary .input 3,  is,  Parentlnput3] 
and  [boundary _input4,  is,  Parentlnput4] 
and  [boundary. inputs,  is,  Parent Input5] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  input.is,  Parentlnputl] 
and  [PaientBox,  input.is,  Parentlnput2] 
and  [ParentBox,  input.is,  Parentlnput3] 
and  [ParentBox,  input.is,  Parentlnput4] 
and  [ParentBox,  input.is,  Parentlnput5] 
then  [’Boundary  Input’,  ’  ’,’  — >  CORRECT:  Boundary  Input 

is  OK’] . 

/*  Boundary  Input  is  not  matched  +/ 

/*  This  rule  includes  all  No.match  case  though  both  of  */ 

/*  parent  and  child  have  the  same  number  of  input  */ 

/*  arrow(s).  */ 

rulel8  ::  if  [child.title,  is,  ParentBox] 
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and  [activityname,  is,  ParentBox] 
then  [’Boundary  Input’,’  ’,’ — >  ERROR:  Boundary  Input  is  not 
matched.  —  You  may  have  at  least  one  unmatched  label’]. 


/********************  About  Boundary  Output  *♦♦♦*♦*♦*******♦********/ 
rulelS  ::  if  [boundary.output ,  is,  ’*] 

then  [’Boundary  Output’,  ’  ’,*  — >  ERROR:  No  boundary  output 

label’] . 


rule20  ::  if  [child.title,  is,  ParentBox] 
and  [ParentBox,  output.is,  ’ ’] 

then  [’Boundary  Output’,’  ’,’  — >  ERROR:  Parent  Output  has  no 

label’] . 


rule21  : :  if  [boundary.output ,  is,  null] 

then  [’Boundary  Output’,’  *,’  — >  ERROR:  No  boundary  output 


arrow . 


Should  have  at  least  one  boundary  output  arrow’] . 


rule22  ::  if  [child_title,  is,  ParentBox] 

and  [ParentBox,  output_is,  null] 
then  [ ’ Boundary  Output 
— >  ERROR:  No  parent  output  arrow. 

Should  have  at  least  one  parent  output  arrow’] . 


/*  The  number  of  Output  arrow(s)  of  the  Parent  Activity  */ 

/*  box  is  differ  from  that  of  the  Boundary  Output  arrow(s).*/ 

/*  The  number  of  the  Parent  Output  arrow (s)  >  The  number  */ 

/♦of  the  Boundary  Output  arrow(s).  ♦/ 

rule23  ::  if  [child.title,  is,  ParentBox] 

and  [ParentBox,  has_output_number ,  OutputNumber] 
and  [boundary.output ,  has.number,  BoundOutNumber] 
and  [OutputNumber,  >,  BoundOutNumber] 
then  [’Boundary  Output’,’  — >  ERROR:  The  number  of  Output 

arrow(s)  of  Parent  Activity  box  is  greater  than  that  of 
Boundary  Output  arrow (s)  —  Must  have  the  same  number’] . 

/*  The  number  of  Output  arrow(s)  of  the  Parent  Activity  box  is  ♦/ 

/♦  differ  from  that  of  the  Boundary  Output  arrow(s) .  ♦/ 

/♦  The  number  of  the  Parent  Output  arrow (s)  <  The  number  of  the  */ 

/♦  Boundary  Output  arrow(s).  */ 

rule24  ::  if  [child.title,  is,  ParentBox] 

and  [ParentBox,  has.output.number ,  OutputNumber] 
and  [boundary.output ,  has.number,  BoundOutNumber] 
and  [OutputNumber,  <,  BoundOutNumber] 
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then  [’Boundary  Output’,’  ’,*  — >  ERROR:  The  number  of  Output 

arrow(s)  of  Parent  Activity  box  is  less  than  that  of 
Boundary  Output  arrow(s)  —  Must  have  the  same  number’] . 

/*  If  the  number  of  arrows  is  greater  than  five,  recomend  */ 

/*  about  how  many  the  number  of  arrows  exists.  */ 

rule25  ::  if  [boundary.output ,  has.number,  BoundOutNumber] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  has.output .number,  BoundOutNumber] 
and  [BoundOutNumber ,  >,  5] 
then  [’Boundary  Output’,  ’  *  — >  RECOMMEND: 

You  would  better  reduce  the  number  of  arrows  to  six 
below’] . 

/*  Consider  the  correct  case  acording  to  the  Number  of  */ 

/*  Output  arrow(s).  */ 

rule26  ::  if  [boundary_output ,  has .number,  BoundOutNumber] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  has.output .number ,  BoundOutNumber] 
then  [case.of_boundary.out,  is,  BoundOutNumber], 

/*  Case  1:  The  number  of  Boundary  Output  arrow  is  1.  */ 

rule27  ::  if  [case. of .boundary.out,  is,  1] 

and  [boundary .output 1 ,  is,  ParentOutput] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  output.is,  ParentOutput] 
then  [’Boundary  Output’,  ’  ’ , *  — >  CORRECT: 

Boundary  Output  is  OK’] . 

/*  Case  2:  The  number  of  Boundary  Output  arrows  is  2.  */ 

rule28  ::  if  [case.of .boundary.out ,  is,  2] 

and  [boundary .output  1 ,  is,  ParentOutputl] 
and  [boundary_output2,  is,  Parent0utput2] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  output.is,  ParentOutputl] 
and  [ParentBox,  output.is,  Parent0utput2] 
then  [’Boundary  Output’,  ’  — >  CORRECT: 

Boundary  Output  is  OK’]. 

/*  Case  3:  The  number  of  Boundary  Output  arrows  is  3.  */ 

rule29  ::  if  [case.of .boundary.out,  is,  3] 

and  [boundary.output 1 ,  is,  ParentOutputl] 
and  [bound ary .output 2,  is,  ParentOutput2] 
and  [boundary_output3,  is,  Parent Output 3] 
and  [child.title,  is,  ParentBox] 
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and  [ParentBox,  output.is,  ParentOutputl] 
and  [ParentBox,  output.is,  Parent0utput2] 
and  [ParentBox,  output.is,  Parent0utput3] 
then  [’Boundary  Output’,  ’  — >  CORRECT: 

Boundary  Output  is  OK*]. 

/*  Case  4:  The  number  of  Boundary  Output  arrows  is  4.  */ 

rule30  ::  if  [case.of.boundary.out,  is,  4] 

and  [boundary .output 1 ,  is,  ParentOutputl] 
and  [boundary_output2,  is,  Parent0utput2] 
and  [boundary .output 3,  is,  Parent0utput3] 
and  [bound ary .output 4,  is,  PaLrent0utput4] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  output.is,  ParentOutputl] 
and  [ParentBox,  output.is,  Parent0utput2] 
and  [ParentBox,  output.is,  Parent0utput3] 
and  [ParentBox,  output.is,  Parent 0utput4] 
then  [’Boundary  Output’,  ’  ’,*  — >  CORRECT: 

Boundary  Output  is  OK’] . 

/+  Case  5:  The  number  of  Boundary  Output  arrows  is  5.  */ 

rule3l  ::  if  [case.of.boundary.out,  is,  5] 

and  [boundary.output 1 ,  is,  ParentOutputl] 
and  [boundary. output2,  is,  Parent0utput2] 
and  [boundary_output3 ,  is,  Parent0utput3] 
and  [boundary_output4 ,  is,  Parent0utput4] 
and  [boundary_output5,  is,  Parent Output 5] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  output.is,  ParentOutputl] 
and  [ParentBox,  output.is,  Parent0utput2] 
and  [ParentBox,  output.is,  Parent 0utput3] 
and  [ParentBox,  output.is.  Parent Dutput4] 
and  [Paren;Box,  output.is,  Parent0utput5] 
then  [’Boundary  Output’,  ’  -->  CORRECT: 

Boundary  Output  is  OK’]. 

/*  Boundary  Output  is  not  matched  */ 

/*  This  rule  includes  all  No.match  case  though  both  of  */ 

/*  parent  and  child  have  the  same  number  of  output  *1 
/*  arrow(s) .  */ 

rule32  ::  if  [child.title,  is,  ParentBox] 

and  [activityname,  is,  ParentBox] 
then  [’Boundary  Output’,’  ’,’ — >  ERROR:  Boundary  Output  is  not 
matched.  --  You  may  have  at  least  one  unmatched  label’]. 


/****************  About  Boundary  Control  ******************/ 
rule33  ::  if  [boundary.control,  is,  * *] 
then  [ ’ Boundary  Control ’ ,  *  * ,  * 

— >  ERROR:  No  boundary  control  label’]. 

rule34  ::  if  [child.title,  is,  ParentBox] 

and  [ParentBox,  control.is,  ’’] 
then  [’Boundary  Control*,’  ’,* 

— >  ERROR:  Parent  Control  has  no  label’]. 

rule35  : :  if  [boundary.control ,  is ,  null] 
then  [’Boundary  Control*,*  *,* 

— >  ERROR:  No  boundary  control  arrow. 

Should  have  at  least  one  boundary  control  arrow’] . 

rule36  ::  if  [child.title,  is,  ParentBox] 

and  [ParentBox,  control.is,  null] 
then  [’Boundary  Control’,  ’  *,  * 

— >  ERROR:  No  parent  control  arrow. 

Should  have  at  least  one  parent  control  arrow’] . 

/*  If  the  number  of  arrows  is  greater  than  five,  recomend  */ 

/*  about  how  many  the  number  of  arrows  exists.  */ 

rule37  ::  if  [boundary.control,  has.number,  BoundConNumber] 
and  [child.title,  is,  ParentBox] 

and  [ParentBox,  has.control.number,  BoundConNumber] 
and  [BoundConNumber,  >,  5] 
then  [’Boundary  Control*,  ’  ’  — >  RECOMMEND: 

You  would  better  reduce  the  number  of  arrows  to  six 
below’]  . 

/*  Consider  the  correct  case  acording  to  the  Number  of  */ 

/*  Control  arrow(s).  */ 

rule38  ::  if  [boundary.control,  has.number,  BoundConNumber] 
and  [child.title,  is,  ParentBox] 

and  [ParentBox,  has.control.number,  BoundConNumber] 
then  [case.of .boundary .con,  is,  BoundConNumber]. 

/*  Case  1 :  The  number  of  Boundary  Control  arrow  is  1 .  */ 

rule39  ::  if  [case.of .boundary .con,  is,  1] 

and  [boundary.control 1 ,  is,  ParentControl] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  control.is,  ParentControl] 
then  [’Boundary  Control’,  ’  ’,*  — >  CORRECT:  Boundary 

Control  is  OK’]. 
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I*  Case  2:  The  number  of  Boundary  Control  arrows  is  2.  */ 

rule40  ::  if  [case.of.boundary.con,  is,  2] 

and  [boundary.controll ,  is.  Parent Control 1] 
and  [boundary_control2,  is,  ParentControl2] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  control.is,  ParentControll] 
and  [ParentBox,  control. is,  ParentControl2] 
then  [’Boundary  Control’,  ’  — >  CORRECT:  Boundary 

Control  is  OK’]. 

/*  Case  3:  The  number  of  Boundary  Control  arrows  is  3.  */ 

rule41  ::  if  [case.of.boundary.con,  is,  3] 

and  [boundary.controll,  is,  ParentControll] 

and  [boundary _control2,  is,  ParentControl2] 

and  [boundary_control3,  is,  ParentControl3] 

and  [child.title,  is,  ParentBox] 
and  [ParentBox,  control.is,  ParentControll] 
and  [ParentBox,  control.is,  ParentControl2] 
and  [ParentBox,  control.is,  ParentControl3] 
then  [’Boundary  Control’,  *  *,’  — >  CORRECT:  Boundary 

Control  is  OK’] . 

/*  Case  4:  The  number  of  Boundary  Control  arrows  is  4.  */ 

rule42  ::  if  [case.of.boundary.con,  is,  4] 

and  [boundary .control 1,  is,  ParentControll] 

and  [boundary. control2,  is,  ParentControl2] 

and  [boundary_control3 ,  is,  ParentControi3] 

and  [boundary_control4,  is,  ParentControl4] 

and  [child.title,  is,  ParentBox] 
and  [ParentBox,  control.is,  ParentControll] 
and  [ParentBox,  control.is,  ParentControl2] 
and  [ParentBox,  control.is,  ParentControl3] 
and  [ParentBox,  control.is,  ParentControl4] 
then  [’Boundary  Control’,  *  ’,’  — >  CORRECT:  Boundary 

Control  is  OK’] . 

/*  Case  5:  The  number  of  Boundary  Control  arrows  is  5.  */ 

rule43  ::  if  [case.of .boundary.con,  is,  5] 

and  [boundary .control 1 ,  is,  ParentControll] 

and  [boundary_control2,  is,  ParentControl2] 

and  [boundary_control3,  is,  ParentControl3] 

and  [boundary. control4,  is,  ParentControl4] 

and  [boundary_control5,  is,  ParentControl5] 

and  [child.title,  is,  ParentBox] 
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and  [ParentBox,  control.is,  ParentControll] 
and  [ParentBox,  control.is,  ParentControl2] 
and  [ParentBox,  control.is,  ParentControl3] 
and  [ParentBox,  control.is,  ParentControl4] 
and  [ParentBox,  control.is,  ParentControl5] 
then  [’Boundary  Control*,  ’  *,*  — >  CORRECT:  Boundary 

Control  is  OK’]. 

/*  Boundary  Control  is  not  matched  */ 

/*  This  rule  includes  all  No.match  case  though  both  of  */ 

/*  parent  and  child  have  the  same  number  of  control  */ 

/*  arrow(s).  */ 

rule44  ::  if  [child.title,  is,  ParentBox] 

and  [activityname,  is,  ParentBox] 
then  [’Boundary  Control’,*  *,*->  ERROR:  Boundary  Control  is  not 
matched.  --  You  may  have  at  least  one  unmatched  label’]. 

/******* *********  About  Boundary  Mechanism  **************/ 
rule45  ::  if  [boundary .mechanism,  is,  ’*] 
then  [’Boundary  Mechanism’ ,  *  *,’ 

— >  ERROR:  No  boundary  mechanism  label*]. 

rule46  ::  if  [child.title,  is,  ParentBox] 

and  [ParentBox,  mechanism. is ,  ’’] 
then  [’Boundary  Mechanism’ , ’  ’,’ 

— >  ERROR:  Parent  Mechanism  has  no  label’]. 

/*  The  number  of  Mechanism  arrow(s)  of  the  Parent  Activity  */ 

/*  box  is  differ  from  that  of  the  Boundary  Mechanism  arrow(s).*/ 

/*  The  number  of  the  Parent  Mechanism  arrow(s)  >  The  number  */ 

/*  of  the  Boundary  Mechanism  arrov(s).  */ 

rule47  ::  if  [child.title,  is,  ParentBox] 

and  [ParentBox,  has.mechanism.number,  MecNumber] 
and  [boundary.mechanism,  has.number,  BoundMecNumber] 
and  [MecNumber,  >,  BoundMecNumber] 
then  [’Boundary  Mechanism’,’  *,* — >  ERROR:  The  number  of 
Mechanism  arrow(s)  of  Parent  Activity  box  is  greater  than  that 
of  Boundary  Mechanism  arrow(s)  —  Must  have  the  same 
number’] . 

/*  The  number  of  Mechanism  arrow(s)  of  the  Parent  Activity  box  is  */ 

/*  differ  from  that  of  the  Boundary  Mechanism  arrow(s) .  */ 

/*  The  number  of  the  Parent  Mechanism  arrow(s)  <  The  number  of  the  */ 

/*  Boundary  Mechanism  arrow(s) .  */ 

rule48  ::  if  [child.title,  is,  ParentBox] 
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and  [ParentBox,  has.mechanism.number ,  MecNumber] 
and  [boundary .mechanism,  has.number,  BoundHecNumber] 
and  [MecNumber,  <,  BoundMecNumber] 
then  [’Boundary  Mechanism*,*  *,’ — >  ERROR:  The  number  of 
Mechanism  arrow(s)  of  Parent  Activity  box  is  less  than 
that  of  Boundary  Mechanism  arrow(s)  —  Must  have  the  same 
number*] . 

I*  If  the  number  of  arrows  is  greater  than  five,  recomend  */ 

/*  about  how  many  the  number  of  arrows  exists .  */ 

rule49  ::  if  [boundary .mechanism,  has.number,  BoundMecNumber] 
and  [child.title,  is,  ParentBox] 

and  [ParentBox,  has.mechanism.number,  BoundMecNumber] 
and  [BoundMecNumber ,  > ,  5] 
then  [’Boundary  Mechanism’,  *  *,  * — >  RECOMMEND: 

You  would  better  reduce  the  number  of  arrows  to  six 
below*] . 

/*  No  boundary  Mechanism  arrow  and  No  Mechanism  at  Parent  Box  */ 
rule50  ::  if  [child.title,  is,  ParentBox] 

and  [boundary .mechanism,  is,  null] 
and  [ParentBox,  mechanism.is ,  null] 
then  [’Boundary  Mechanism’,  *  ’,’ — >  CORRECT:  Boundary 
Mechanism  is  OK*]  . 

/*  Consider  the  correct  case  acording  to  the  Number  of  */ 

/*  Mechanism  arrow(s).  */ 

rule51  ::  if  [boundary .mechanism,  has.number,  BoundMecNumber] 
and  [child.title,  is,  ParentBox] 

and  [ParentBox,  has.mechanism.number,  BoundMecNumber] 
then  [case.of .boundary _mech,  is,  BoundMecNumber]. 

/*  Case  1:  The  number  of  Boundary  Mechanism  arrow  is  1.  */ 

rule52  ::  if  [case.of .bound ary _me ch ,  is,  1] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  mechanism.is,  ParentMech] 
and  [boundary .mechanisml ,  is,  ParentMech] 
then  [’Boundary  Mechanism’,  ’  *,’ — >  CORRECT:  Boundary 
Mechanism  is  OK’] . 

/*  Case  2:  The  number  of  Boundary  Mechanism  arrows  is  2.  */ 

rule53  ::  if  [case.of .boundary .rnech,  is,  2] 

and  [boundary .mechanisml,  iB,  ParentMechl] 
and  [bound ary .rnech an ism2,  is,  ParentMech2] 
and  [child.title,  is,  ParentBox] 
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and  [ParentBox,  mechanism. is,  ParentMechl] 
and  [ParentBox,  mechanism.is,  ParentMech2] 
then  ['Boundary  Mechanism’,  ’  CORRECT:  Boundary 

Mechanism  is  OK']. 

/*  Case  3:  The  number  of  Boundary  Mechanism  arrows  is  3.  */ 

rule54  ::  if  [case.of .boundary _mech,  is,  3] 

and  [boundary .mechanisml,  is,  ParentMechl] 
and  [boundary _mechanism2 ,  is,  ParentMech2] 
and  [boundary_mechanism3,  is,  ParentMech3] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  mechanism.is,  ParentMechl] 
and  [ParentBox,  mechanism.is,  ParentMech2] 
and  [ParentBox,  mechanism.is,  ParentMech3] 
then  [’Boundary  Mechanism’,  ’  CORRECT:  Boundary 

Mechanism  is  OK’] . 

/*  Case  4:  The  number  of  Boundary  Mechanism  arrows  is  4.  */ 

ruleSS  ::  if  [case.of .boundary _mech,  is,  4] 

and  [boundary .mechanisml ,  is,  ParentMechl] 
and  [boundary _mechanism2,  is,  ParentMech2] 
and  [boundary .mechanism3 ,  is,  ParentMech3] 
and  [boundary _mechanism4 ,  is,  ParentMech4] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  mechanism.is,  ParentMechl] 
and  [ParentBox,  mechanism.is,  ParentMech2] 
and  [ParentBox,  mechanism.is,  ParentMech3] 
and  [ParentBox,  mechanism.is,  ParentMech4] 
then  [’Boundary  Mechanism’,  ’  ’,’ — >  CORRECT:  Boundary 
Mechanism  is  OK’]. 

/*  Case  5:  The  number  of  Boundary  Mechanism  arrows  is  5.  */ 

rule56  ::  if  [case.of .boundary _mech,  is,  5] 

and  [boundary .mechanisml ,  is,  ParentMechl] 
and  [boundary _mechanism2,  is,  ParentMech2] 
and  [boundary _mechanism3,  is,  ParentMech3] 
and  [boundary _mechanism4,  is,  ParentMech4] 
and  [boundary .mechanism5,  is,  ParentMech5] 
and  [child.title,  is,  ParentBox] 
and  [ParentBox,  mechanism.is,  ParentMechl] 
and  [ParentBox,  mechanism.is,  ParentMech2] 
and  [ParentBox,  mechanism.is,  ParentMech3] 
and  [ParentBox,  mechanism.is,  ParentMech4] 
and  [ParentBox,  mechanism.is,  ParentMech5] 
then  [’Boundary  Mechanism’,  ’  ’,’ — >  CORRECT:  Boundary 
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Mechanism  is  OK’] . 


/*  Boundary  Mechanism  is  not  matched  */ 

/*  This  rule  includes  all  No.match  case  though  both  of  */ 

/*  parent  and  child  have  the  same  number  of  mechanism  */ 

/*  arrow(s).  */ 

rule57  ::  if  [child.title,  is,  ParentBox] 

and  [activityname ,  is,  ParentBox] 
then  [’Boundary  Mechanism’ , ’  ’,’ 

— >  ERROR:  Boundary  Mechanism  is  not 

matched.  —  You  may  have  at  least  one  unmatched  label’]. 
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